On Wed, Oct 5, 2011 at 2:49 AM, Bruce Momjian <br...@momjian.us> wrote:
> 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. I don't actually see it would be a big problem quicksort to start up a bunch of threads which do some of the work and go away when the tuplesort is done. As long as the code they're executing is well defined and limited to a small set of code that can be guaranteed to be thread-safe it should be reasonably simple. The problem is that in most of the Postgres core there aren't many places where much code fits that description. Even in tuplesort it can call out to arbitrary user-defined functions so we would need a way to mark which functions are thread-safe. Beyond integer and floating point comparisons it may not be much -- certainly not Numeric or strings due to detoasting... And then there are things like handling the various signals (including SI invalidations?) and so on. I agree that if we wanted to farm out entire plan nodes we would probably end up generating new partial plans which would be handed to other backend processes. That's not unlike what Oracle did with Parallel Query. But i'm a bit skeptical that we'll get much of that done in 2-3 years. The main use case for Parallel Query in Oracle is for partitioned tables -- and we haven't really polished that after how many years? -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
