Tuesday, January 04, 2011

PostgreSQL 9.1: Big Patches

About three weeks ago, I wrote a blog post about the forthcoming end of the PostgreSQL 9.1 development cycle, and the many large and important features for which we have patches outstanding.  Since we now have just 11 days to go before the beginning of the forth and final CommitFest, this seems like a good time to revisit the progress we've made.  Here again is the list of features from my previous post:

1. SQL/MED.  Over Christmas, I committed a chunk of this work, after heavy revisions.  As a result, the CREATE FOREIGN TABLE, ALTER FOREIGN TABLE, and DROP FOREIGN TABLE commands now exist in PostgreSQL.  However, foreign tables can't actually be queried yet.  For that to happen, we need support for "foreign table scans".  We are currently waiting for an updated patch.

2. Extensions.  Dimitri Fontaine has continued to update his patch set, and is working on a further patch to allow extensions to be upgraded, but to the best of my knowledge no committer has yet agreed to work on getting this committed.

3. Synchronous Replication.  Activity on this appears to have kicked into high gear again, with Simon Riggs taking the lead, but a final patch has not yet been submitted.  Several small patches to improve replication in other ways and/or simplify the final patch are under way also.

4. Writable CTEs.  To the best of my knowledge, Tom Lane is still planning to handle this patch, but no movement yet.

5. Per-column collation.  No activity.

6. MERGE.  There has been further discussion of this patch, by Greg Smith and others, but I believe there's still a significant amount of code review that needs to be done.

7. Checkpoint improvements.   Greg Smith reports that he is still working on this, but no updated patch yet.

8. SE-Linux integration.  I committed the last bits of infrastructure that I believe we need for a bare-bones implementation of this feature on December 13.  KaiGai Kohei posted a stripped down sepgsql contrib module on December 23.  I plan to review it, but have not had time yet.

9. Unlogged tables.  Committed!  For some test results, see depesz's blog post on unlogged tables.

10 comments:

  1. any word on index-only scan patch?

    ReplyDelete
  2. I think that's basically not going to happen for 9.1. I may work on it for 9.2.

    ReplyDelete
  3. any news on new syntax for partitioning?

    ReplyDelete
  4. I think postgresql develoeprs in general didn't liked any presented solutions to the partitioning problem so far. Nor they are keen on actually writing their own. Really weird for what is supposedly enterprise grade database.

    ReplyDelete
  5. Itagaki Takahiro was working on the partitioning syntax back in July, but hasn't to my knowledge revised it recently. I think there is general agreement on what the syntax should look like; it was primarily the system catalog representation that was under discussion.

    ReplyDelete
  6. Without parallel query, much of the benefit of partitions are not seen.

    You can get most of the performance boost you are looking for with partial indexes. It does not partition the data, but it does effectively partition the index.

    ReplyDelete
  7. Yay for unlogged tables. That and sync rep are the big ones for me.

    For sync rep, I think this is going to be so hot that everyone and their mother is going to have an opinion.

    I hope they can just start with the one (as it looks like they are planning) and we can go from there.

    The only parameter I care about is the configurable durability on the standby (ie, just ack on received or all the way to disk etc).

    Good luck!

    ReplyDelete
  8. Hi,

    any info on when inheritance will be fully implemented?

    And thanks for a great DBMS!

    ReplyDelete
  9. Sync rep will be useful for some people, but it's likely to come with a pretty high performance cost, as it does in other products, so I'm not sure how many people will want to pay that cost.

    With respect to inheritance being fully implemented, I'm not sure what this is referring to.

    ReplyDelete
  10. What do you mean?

    ReplyDelete