Re: PostgreSQL Parallel Processing ! - Mailing list pgsql-performance

From Claudio Freire
Subject Re: PostgreSQL Parallel Processing !
Date
Msg-id CAGTBQpaS1DeN8hpq=Rb4Q9JkR4JrCucwgaP1wW7T48K9tbWO0Q@mail.gmail.com
Whole thread Raw
In response to Re: PostgreSQL Parallel Processing !  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: PostgreSQL Parallel Processing !  (sridhar bamandlapally <sridhar.bn1@gmail.com>)
List pgsql-performance
On Wed, Jan 25, 2012 at 5:16 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Wed, Jan 25, 2012 at 7:43 AM, Claudio Freire <klaussfreire@gmail.com> wrote:
>> I know squat about how to implement this, but I've been considering
>> picking the low hanging fruit on that tree and patching up PG to try
>> the concept. Many of the items above would require a thread-safe
>> execution engine, which may be quite hard to get and have a
>> significant performance hit. Some don't, like parallel sort.
>
> This was just discussed on -hackers yesterday -- see thread
> 'multithreaded query planner'.  In short, judging by the comments of
> some of the smartest people working on this project, it sounds like
> using threads to attack this is not going to happen, ever.  Note you
> can probably still get parallel execution in other ways, using
> processes, shared memory, etc, so I'd consider researching in that
> direction.

If you mean this[0] thread, it doesn't show anything conclusive
against, say, parallel sort or pipelining.

But I agree, checking the code, it would be really tough to get any
more than parallel sorting by primitive types with threads.

Processes, however, show promise.

[0] http://archives.postgresql.org/pgsql-hackers/2012-01/msg00734.php

pgsql-performance by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: PostgreSQL Parallel Processing !
Next
From: "Carlo Stonebanks"
Date:
Subject: pl/pgsql functions outperforming sql ones?