This week I did something I'd prefer to never repeat: I left the country, did something useful, and made it back again in the same day. The occasion was the FreeBSD Developer Summit, held just before BSDCan--the convention that happens in Ottawa the week before PGCon every year. So I get to head right back again next week, but stay a while that time.The FreeBSD developers were nice enough to sponsor my trip so that we could talk about both the business and technical hurdles that I felt were keeping the sort of companies I work with from deploying their databases on FreeBSD more often than they do. My slightly updated slides are available on our talks page, I cleaned up a couple of things from what was presented (the most important rewording I'll talk about below).I
If you have a Linux server of the RedHat family (inclusing CentOS and Fedora), you might envy the way Debian/Ubuntu distributions handle PostgreSQL clusters management.
Although it is not easy to install different PostgreSQL versions on the same RedHat Linux server using RPMs, it is much simpler to install several instances of PostgreSQL (servers) and, at the same time, take advantage of the services infrastructure.
If you're running Linux, and particularly if you're running a database on Linux, it's been hard to recommend any filesystem other than plain old ext3 in recent years. Some of the alternatives that looked interesting at one point--jfs, ReiserFS--are completely abandoned at this point. The one that has been almost viable for some time now is XFS, originally an SGI projecs. And it's back to being in the limelight again this week.XFS had suffered from a number of problems in the past. Since it was designed for stable hardware, it wasn't as robust on standard cheap PC hardware at first; quite a bit of that was just cleaned up two years ago. It had this odd problem with zeroed files that scared some people off. It was treated as a second-class citizen in
A few weeks ago I presented an updated 2010 version of my talk on database hardware benchmarking at PG East; slides available from our talks page. CPU and memory performance are particularly important for a PostgreSQL database, because every individual query runs as a single process. Therefore, the speed of your fastest core determines how fast any one query can execute at, and in modern systems that's quite likely to bottleneck based on memory speed.One of the things that's obvious from recent memory speed results is that all of AMD's processors have been stuck in a distant second place for almost 18 months now. While AMD continues to use DDR2-800, Intel's "Nehalem" processors, shipping in volume since early 2009, have been adopting increasingly fast DDR3 in good
Today is the deadline for the special room rate at the hotel hosting this month's PostgreSQL Conference East 2010. If you've been procrastinating booking a spot at the conference, as of tomorrow that will start costing you.My talk is on Database Hardware Benchmarking and is scheduled for late afternoon on the first day, Thursday March 25th. Those who might have seen this talk before, either live at PGCon 2009 or via the video link available there, might be wondering if I'm going to drag out the same slides and talk again. Not the case; while the general philosophy of the talk ("trust no one, run your own benchmarks") stays the same, the examples and test mix suggested have been updated to reflect another year worth of hardware advances, PostgreSQL work, and my own
The new Hot Standby feature in the upcoming PostgreSQL 9.0 allows running queries against standby nodes that previously did nothing but execute a recovery process. Two common expectations I've heard from users anticipating this feature is that it will allow either distributing short queries across both nodes, or allow running long reports against the standby without using resources on the master. These are both possible to do right now, but unless you understand the trade-offs involved in how Hot Standby works there can be some unanticipated behavior here.
Standard Long-running Queries
One of the traditional problems in a database using MVCC, like PostgreSQL, is that a long-running query has to keep open a resource--referred to as a snapshot in the current Postgres implementation--to
Checkpoints can be a major drag on write-heavy PostgreSQL installations. The first step toward identifying issues in this area is to monitor how often they happen, which just got an easier to use interface added to the database recently.