On Sun, Mar 27, 2005 at 23:58:35 -0500,
Mike Mascari <mascarm@mascari.com> wrote:
>
> 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 think that is a bit extreme. For some queries you will be able to
parallelize accross mutliple back ends and realize some speedup.
I would also think that this argument could also apply to cases where
the data is on several sets of disks and you wanted to be reading from
both sets at once rather than serially.
> 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...
I think there are other things that could be done to improve optimization
that will benefit more people than parallelized queries. Those are really only
useful to people where the database is being used by a handful (less than
the number of processors and/or disk channels) of users concurrently, who
are making long running queries and waiting for the results.