Back in July, I wrote a blog post on the best patches submitted for the first CommitFest for PostgreSQL 9.1 development (so far, the first two out of the three have been committed). I didn't end up writing a similar post for the second CommitFest, because there wasn't a lot of stuff that really grabbed my attention, but the third CommitFest is here now, and there are a ton of exciting patches.
1. Extensions. Dimitri Fontaine has submitted a series of patches (pg_execute_from_file(), cfparser, extensions, ALTER OBJECT any_name SET SCHEMA name, ALTER EXTENSION ... SET SCHEMA ...) to allow packaging of SQL objects into bundles called extensions. PostgreSQL has a great framework for extensibility, but up until now we have not had a good packaging mechanism around that extensibility. This work will hopefully provide that packaging framework, simplifying installation, upgrade, and removal of packages and facilitating upgrades from one major version to the next. Several of these patches still need reviews - please volunteer your time to help the project!
2. Checkpoint Improvements. Greg Smith, with Simon Riggs, have submitted a series of patches (Count backend self-sync calls, Instrument checkpoint sync calls, Spread checkpoint sync) to instrument and improve PostgreSQL's checkpoint behavior. Although this has been much improved in versions 8.3 and higher, Greg has found that there can still be situations where pathological behavior occurs, and that newer versions of the Linux kernel and XFS permit additional optimization of the algorithm that would not have helped in the past. He spoke about this in his Righting Your Writes talk at PostgreSQL West.
3. SQL/MED. Shigeru Hanada has submitted the largest patch I have ever seen to implement SQL/MED support for PostgreSQL. I have a suspicion we're going to need to find some kind of intelligent way to slim this down to a more manageable size for reviewing purposes, but it's fantastic that this kind of work is happening in our community. SQL/MED means accessing external data sources, such as other databases, CSV files, memcached instances, or any other sort of data source you can imagine, as if they were SQL objects. Regardless of how much of this gets committed to PostgreSQL 9.1, it's not going to be everything that we ever want to have in this area. But it's a start.
In addition to that, there is my work on unlogged tables, which I've blogged about previously, KNN-GIST, which aims to allow GIST indexes to perform K-nearest neighbor searches (but still seems to need a fair amount of work), writeable CTEs, and of course several patches related to synchronous replication. And there's more good stuff too, but I can't tell you about all of them in this blog post. What we're really seeing with this CommitFest is the major work of nearly all the major PostgreSQL contributors landing in the patch queue. As a result, although the number of patches needing review is not particularly higher than any other CommitFest we've had recently, the average complexity is really high. We could really use some help reviewing.