A database query planner is an optimizing compiler. It's also a major field of research, and in many ways, much more sophisticated than other kinds of optimizing compilers.
In particular, it doesn't just optimize your algorithm, it chooses better algorithms for you.
It does this by collecting statistics about the data (and keeping them up to date), and using those statistics to estimate the inputs to each operator in a candidate plan (a combination of algorithms that answers the query), and then estimate costs, and choose the candidate plan with the lowest cost.
(The above explanation is simplified and not entirely accurate. It discards most candidate plans before they even really become a plan. And "candidate plan" is not really the right terminology, but I thought it was more descriptive at a high level.)
As if the HN homepage is an instant badge of honor.
It has seen it's share of lame stories over the years.
That said, it doesn't matter if the post has any content. It's enough that it invokes an interesting topic for HN readers to discuss about. Same as "ASK HN" posts have no content at all, just the title, as a basis for discussion.
For the record, 9.3 is the next version to be released, and 9.5 is not even on the radar.
Also, there are no specific plans for doing parallel query execution (that is, parallelizing a single query) in a major way any time soon. And parallel query execution can mean many things and take many forms.
Postgres is already good at parallel execution of many different queries.
I know 9.3 is the next version. With 9.5, I meant to indicate parallel query execution won't happen for a long time, not likely in 9.4, but perhaps in 9.5.
Developers are relying more and more on database systems to solve their scalability needs.
If you didn't have a database, you'd need to make sure to get the locking right even when doing completely different queries. A SQL database solves that problem by doing the concurrency control for you (possibly with locks, possibly not). That's what allows a developer to quickly and easily make a reasonably complex application that scales to many concurrent queries.
(Sure, it sounds easy to add in a couple locks, or use STM. But then you need to make all of that work efficiently and also enforce unique constraints or something, and it starts to get a little more complex. Pretty soon you'll want secondary indexes, and a buffer pool, and checkpoints, etc.)
Postgres even added in an efficient version of True Serializability[1], which eliminates SQL race conditions.
So, can this all be extended to help with parallel execution of a single query? Yes. Some systems have had parallel query for a while, and cluster systems are also a different form of parallelism.
In particular, it doesn't just optimize your algorithm, it chooses better algorithms for you.
It does this by collecting statistics about the data (and keeping them up to date), and using those statistics to estimate the inputs to each operator in a candidate plan (a combination of algorithms that answers the query), and then estimate costs, and choose the candidate plan with the lowest cost.
(The above explanation is simplified and not entirely accurate. It discards most candidate plans before they even really become a plan. And "candidate plan" is not really the right terminology, but I thought it was more descriptive at a high level.)