Query Planning Gone Wrong: The Video

If you missed my talk on Query Planning Gone Wrong at PGCon and Postgres Open, but you'd still like to hear it, videos of both versions of the presentation are available on YouTube.  Here's me giving the talk the first time, at PGCon, and here I am giving it again, at PG Open.

Parallelism Progress

For the last several months, I have been spending a large percentage of my time trying to bring parallelism to PostgreSQL.  Previous blog posts on the future direction of PostgreSQL development have often mentioned this as a priority, although the top spot has usually been reserved for materialized views, a feature which now exists in PostgreSQL 9.3 and which has been improved in PostgreSQL 9.4.  My colleague at EnterpriseDB, Kevin Grittner, is continuing to work on further improvements in that area.  But my focus is on parallelism.  So, how's that going?

MVCC Catalog Access

Some wag, riffing on Rudyard Kipling, once wrote that "if you can keep your head when all around you are losing theirs, maybe you just don't understand the situation".  I thought of that line this morning, while committing a patch to use MVCC snapshots for system catalog access.

Query Planning Gone Wrong

Over the past few years, I've been making notes on pgsql-performance postings, specifically those postings which relate to query performance issues.  Today, I gave a talk at PGCon on the data I've been able to gather.

If you attended the talk, please leave feedback through the PGCon web site or feel free to leave a comment below with your thoughts.  If not, you can find the slides on my Presentations web page.  A few people asked me to post the raw data on which the talk was based, including links to the original threads.  I have created a Query Performance section on my Google Site and posted the information there.

The version posted on the web site incorporates a few minor corrections as compared to what I presented in the talk; and I have left out (for the sake of politeness) the cases I attributed to user error.  There were actually only 2 such cases, not 3 as I said in the talk, but either way it seems more polite not to post specific links.  Please contact me if you find other mistakes in what I have posted and I will correct them.

Many thanks to all those who said nice things about my talk!

Confronting The Big Issues

In the last few years, PostgreSQL has added a number of impressive new features, such as built-in replication (both synchronous and asynchronous), SQL/MED foreign tables (which, in the forthcoming 9.3 release, will also support writes), per-column collation support and in-place upgrade.  There are have also been so fairly major performance improvements and a host of new smaller features.  While all of this progress is impressive, it is clear that too little time and energy has been spent confronting the project's biggest weakness: its unpronounceable name.

As Wikipedia helpfully explains, PostgreSQL's ancestor was the INGRES project of the University of California at Berkeley.  INGRES stands for "interactive graphics retrieval system", but hackers like plays on words, so after a decent amount of hacking on that code had been done, some wit thought it would be a fine idea to replace the prefix "in" with "post", to connote that the project had gone beyond Ingres.  Furthermore, since the system was modified to support SQL, some other wit decided it would be a good idea to replace the last syllable (but only half of it) with the name of the query language it now supported.  Fortunately, we're moving away from that, but that's how we ended up the name PostgreSQL which, as you can now understand, stands for "beyond the graphics retrieval structured query language".