According to the PostgreSQL 9.1 development plan, the final CommitFest for PostgreSQL 9.1 development will begin in 33 days. Approximately 30 days later, we'll stamp our final alpha release and begin preparations for PostgreSQL 9.1 beta. This is exciting news, because I'm really looking forward to PostgreSQL 9.1. It's also scary news, because there is a lot of work left to be done between now and then, and at least in the United States, Christmas is going to take a bite out of that time.
We have a number of very interesting, very significant features which were submitted to the 2010-11 CommitFest. These include SQL/MED, extensions, synchronous replication, writeable CTEs, per-column collation, MERGE, checkpoint improvements, further infrastructure for SE-Linux integration, and my own work on unlogged tables. While we've made significant progress on most of these features during this CommitFest, major work still remains to be done on nearly all of them, and none of them can be considered a sure thing for PostgreSQL 9.1. It's possible - maybe even likely - that even more worthwhile features will be added to the queue between now and mid-January.
So it's crunch time. We have about two months to define what PostgreSQL 9.1 will be. Let's make the most of it.
when is the next alpha? (not final)
ReplyDeleteI like all the features, but per-column collation is awesome.
ReplyDeleteBut, apparently, we will haven't a long waited feature: transparent table partitioning...
Oracle, DB2, SQL Server and even MySQL, have this feature that improves speed in a large use cases.
Next alpha will be RSN, not sure exactly when.
ReplyDeleteLot's of great stuff. Some really time consuming patches as well, always impressive to see the dev effort.
ReplyDeleteI'm keeping my fingers crossed for at least sync replication solution to get in and unlogged tables.
I hope that a simple version of either sync solution get's in, and then we can worry about quorum commits etc.
The unlogged tables idea is super fantastic, especially if every problem looks like a nail to the postgresql hammer. Sometimes I just don't want to spend the time on a separate solution, and we potentially won't need to with unlogged tables for transient / intermediate data.