Re: Inlining comparators as a performance optimisation - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Inlining comparators as a performance optimisation
Date
Msg-id 201110050149.p951neF09160@momjian.us
Whole thread Raw
In response to Re: Inlining comparators as a performance optimisation  (Peter Geoghegan <peter@2ndquadrant.com>)
Responses Re: Inlining comparators as a performance optimisation
List pgsql-hackers
Peter Geoghegan wrote:
> On the subject of highly ambitious optimisations to sorting, one
> possibility I consider much more practicable than GPU-accelerated
> sorting is simple threading; quicksort can be parallelised very
> effectively, due to its divide-and-conquer nature. If we could agree
> on a threading abstraction more sophisticated than forking, it's
> something I'd be interested in looking at. To do so would obviously
> entail lots of discussion about how that relates to whatever way we
> eventually decide on implementing parallel query, and that's obviously
> a difficult discussion.

I agree that the next big challenge for Postgres is parallel operations.
With the number of cores increasing, and with increased memory and SSD,
parallel operation is even more important.  Rather than parallelizing
the entire backend, I imagine adding threading or helper processes for
things like sorts, index scans, executor nodes, and stored procedure
languages.  I expect final code to be 2-3 years in the future.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bug with pg_ctl -w/wait and config-only directories
Next
From: Marti Raudsepp
Date:
Subject: Re: [PATCH] Log crashed backend's query v2