PostgreSQL 9.0 is in the can and is coming to the end of post-production. Still looking forward to the usual last minute special effects by ILM (Industrial Lane & Magic) to pull some extra zing into performance.
So what next? Well, three genres attract my attention: High performance ("OLTP"), Replication and Data Warehousing. The first two are action features, while the last one is more of a romance for me. Some of the stunts for the first two are similar, so we'll be looking to reduce production costs with some clever thinking.
No blockbusters this year, though hopefully some worthwhile features.
High performance stuff we hope for in 9.1 will be
* Group commit
* MERGE related stuff - production costs stalled the first attempt to bring this to the big screen, though some Euro sponsorship should make this viable. Hoping that Greg Smith will take the lead role on this cos its a big performance critical project, with some hard bits.
* Some surprise features!
Replication
* Synchronous replication
* Relay replication
* Fast switchover - an art house flick with a small, yet good following
Data Warehousing features for 9.1 will be
* Bit map indexes - has had its script rewritten a few times and the actors have changed as well, though it really needs to happen this time around cos its just so cool.
I also expect to keep my eye on Partitioning features to ensure it actually works for the use cases we care about, which is Big Data.
Dancing is a key element of Bollywood and the best bits are when everyone gets involved in huge Busby Berkeley numbers. Expecting the dancing to be particularly intense for Synchronous Replication though the dancers are also fairly well trained, so we're hoping for a happy ending with a cool soundtrack.
Unsure if its a promise I can keep, but no more features with the word "Hot" in the title, especially since the dance routines are so long.
Not going to Cannes this year, but I will be appearing at the Brits: www.char10.org
Subscribe to:
Post Comments (Atom)
Posts
Would LOVE to see merge and bitmap indexes.
ReplyDeleteWe have a GSoC student working on MERGE command:
ReplyDeletehttp://wiki.postgresql.org/wiki/Add_MERGE_command_GSoC_2010
It's a tough feature, so he'll need help from the community to get the design right. I'm not sure why this was listed under high performance stuff, though. Maybe it helps with performance, but I believe most people are most interested in that to have a handy syntax for "update if exists, otherwise insert". And for general SQL compliance reasons, of course.
MERGE is listed under high performance because if you can do a single statement rather than 2 plus a subtransaction loop and specific code then it will be much faster with the right implementation.
ReplyDeleteI'm aware of the project. I think it's irresponsible of people to have allowed an important and complex feature be done in this way. It's unreasonable to expect that the poor chap will get much done at all. We shouldn't be actively handing the hardest tasks we have to the least experienced, however talented and full of promise they may be (and I'm sure they are). It's not fair on them and it is likely to delay the eventual implementation by doing it, which risks slipping a release. That's exactly what happened with partitioning and its been delayed for years as a result. Parallel query etc.. Having said that Hot Standby came out of a student project and was an excellent piece of initial research, so we'll have to wait and see.