Re: Support Parallel Query Execution in Executor - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Support Parallel Query Execution in Executor
Date
Msg-id 28812.1144533766@sss.pgh.pa.us
Whole thread Raw
In response to Re: Support Parallel Query Execution in Executor  ("Jonah H. Harris" <jonah.harris@gmail.com>)
Responses Re: Support Parallel Query Execution in Executor  ("Jonah H. Harris" <jonah.harris@gmail.com>)
Re: Support Parallel Query Execution in Executor  ("Gregory Maxwell" <gmaxwell@gmail.com>)
List pgsql-hackers
"Jonah H. Harris" <jonah.harris@gmail.com> writes:
> On 4/8/06, Markus Schiltknecht <markus@bluegap.ch> wrote:
>> Ehm.. which additional I/O cost? Or do you count inter-process
>> communication to I/O?

> Inter-process will add a minimal amount, but if it's done correctly,
> you'll still end up ahead.

This is exactly the bit of optimism I was questioning.  We've already
been sweating blood trying to reduce multiprocessor contention on data
structures in which collisions ought to be avoidable (ie, buffer arrays
where you hope not everyone is hitting the same buffer at once).  I
think passing large volumes of data between different processes is going
to incur quite a lot of locking overhead, pipeline stalls for cache line
transfers, etc, etc, because heavy contention for the transfer buffer is
simply not going to be avoidable.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: FOUND not set by EXECUTE?
Next
From: David Fetter
Date:
Subject: Re: How to implement oracle like rownum(function or seudocolumn)