Re: Support Parallel Query Execution in Executor

Josh Berkus  writes:
> Basically reading a large table off disk does this:

> read some table while not processing
> process in cpu while not reading
> read some more table while not processing
> process some more in cpu while not reading
> etc.
> resulting in an I/O througput graph that looks like:

>     *       *       *
>    * *    * *    * *
>   *    * *    * *    *
>  *       *       *      *

Interesting ...

> The really annoying part about this, for me personally, is that the peaks 
> are significantly faster than comparable commercial DBMSes ... but our 
> average is far less.   So even on a single seq scan, parallel query 
> execution would make a significant difference in performance, possibly as 
> much as +75% on seq scans of large tables.

... but I'm failing to follow where it says that parallel processing 
will fix that.  All I can foresee in that direction is extra data
transfer costs, bought at the price of portability and locking headaches.
		regards, tom lane