Parallel Query should be a top priority

PostgreSQL has made substantial progress over the years and is
approaching enterprise-quality feature sets. However, one of the major
stopping points for enterprise deployment is lack of parallel query
support. DB2, Oracle, even SQL Server Enterprise Edition all have
parallel query support. A recent Dr. Dobbs Journal documented how
Moore's Law is no longer applicable - processor speeds are increasing at
a decreasing rate. Large boxes, such as Sun Enterprise 25000's, have
large quantities of UltraSPARC III and IV processors, whose SPECint
ratings are inferior to that of less-scalable Opterons (as an example.)
In these configurations, Oracle performs exceeding well, because it has
multiple paths for parallelization of a single query:

http://www.pafumi.net/parallel_query.htm

Without parallel query, the *only* way to decrease the execution time of
a single query whose data has been fully cached is to buy the
latest-and-greatest which is increasing in speed at decreasing rates,
rather than scaling up the number of processors in a single box. A speed
barrier to PostgreSQL's ability to execute a single query is fast
approaching.

I love PostgreSQL, and with tablespaces, PITR, nested transactions, and
more PLs than one knows what do with, it's my favorite database from a
usability standpoint. But in terms of performance, the one missing
piece to the performance puzzle is parallel query.

"Consider parallel processing a single query" should be moved out from
under Miscellaneous on the TODO list and re-categorized as the formerly
existent URGENT feature...

Mike Mascari