Horton

Re: why not parallel seq scan for slow functions

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-09-06T20:03:56Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Sep 6, 2017 at 3:41 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm not entirely following.  I thought that add_path was set up to treat
>> "can be parallelized" as an independent dimension of merit, so that
>> parallel paths would always survive.

> Here, the Gather path is not parallel-safe, but rather
> parallel-restricted:

Ah, right, the problem is with the Gather not its sub-paths.

>> Might be a tad messy to rearrange things that way.

> Why do you think I wanted you to do it?  :-)

I'll think about it.

			regards, tom lane

Commits

  1. Rewrite the code that applies scan/join targets to paths.

  2. Teach create_projection_plan to omit projection where possible.

  3. Make the upper part of the planner work by generating and comparing Paths.