PostgreSQL 9.1 In Review

As the PostgreSQL 9.1 development cycle winds down to a close (we're now in beta), I find myself reflecting on what we got done during this development cycle, and what we didn't get done.  Just over a year ago, I published a blog post entitled Big Ideas, basically asking for feedback on what we should attempt to tackle in PostgreSQL 9.1.  The feedback was overwhelming, and led to a follow-on blog post summarizing the most-requested features.  Here's the short version: Of the 10 or 11 most requested features, we implemented (drum roll, please) one.  Credit for granular collation support goes to Peter Eisentraut, with much additional hackery by Tom Lane.

You can find a second list of possible 9.1 features in the minutes of the PGCon 2010 Developer Meeting.  Of the 30 features listed there, we got, by my count, 12.5, or more than 40%.  While even that may seem like a somewhat small percentage, a dozen or so major enhancements to the development process is nothing to sneeze at.  And certainly, if you were a feature longing to be implemented, you'd much prefer to be on the second list than the first.

What accounts for the difference between the first list (very little of which got implemented) and the second list (much more of which did)?  I think there are two main factors.  First, a list of user requirements need not and does not limit itself to realistic goals, whereas developers typically don't plan on working on things that are too far beyond the realistic hope of success.  Second, and not to be overlooked, the second list reflects the priorities of the developers, not the users.  And since the developers are the ones doing the work, they get to call the shots.

This may sound a bit harsh.  After all, shouldn't the developers choose to work on the projects that the users want done?  Of course, in a corporate setting, that's exactly what happens: management sets priorities based on what they think will help them make the most money, and the developers work on those projects (or get fired).  But PostgreSQL is not a company: it's a community.  All of the developers are also users; any user who happens to write code is by that very fact a developer.

The great thing about this system is that, if there's some feature you're really passionate about, you can make it happen.  There isn't some company or elite group of individuals who sets the road-map for PostgreSQL, such that anyone outside that key decision-making body is unable to have input into the process.  If you want a particular feature implemented, you can put it on the road-map yourself.

As you might expect, this system is not without its drawbacks.  Even if many people want some particular feature, it may be that no single person wants it badly enough to put in the necessary effort to make it happen, especially if the feature is technically challenging.  Sometimes, two people will collaborate to complete work on a feature, but it is still the case that work on a majority of features is driven largely by single individuals.  There have been a few efforts to solve this problem through a "bounty" system, where several sponsors combine to pay for the development of a significant feature, and those efforts have, I think, met with success in some cases.  I hope that this activity will increase.  I suspect there are many companies out there who could fund the development of whichever features PostgreSQL would need to have to meet their use case for a fraction of the cost of licensing a competing commercial product.

With PostgreSQL 9.1 now in beta, I'm starting to look ahead to PostgreSQL 9.2.  I am planning to spend put a significant chunk of time into working on index-only scans.  I've also developed a quick patch to implement time-delayed replication, but that may need a good bit more work before it is judged committable.  I'm not too sure what else I'll be working on yet, but I hope there will be a few more interesting projects as well.  I am also looking forward to seeing work from several other contributors which was begun at the end of the 9.1 cycle completed during the 9.2 cycle - in particular, Alvaro Herrera's work on key locks, and Jeff Davis's work on range types.