Re: Pushdown target list below gather node (WAS Re: WIP: Upper planner pathification) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Pushdown target list below gather node (WAS Re: WIP: Upper planner pathification)
Date
Msg-id 20081.1458147468@sss.pgh.pa.us
Whole thread Raw
In response to Re: Pushdown target list below gather node (WAS Re: WIP: Upper planner pathification)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Pushdown target list below gather node (WAS Re: WIP: Upper planner pathification)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Mar 16, 2016 at 12:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> And there is a larger problem with this: I'm not sure that it's
>> appropriate for apply_projection_to_path to assume that the subpath is not
>> shared with any other purposes.  If it is shared, and we update the
>> subpath's target in-place, we just broke the other path chains.

> That's true.  I don't see an obvious hazard here, because the Gather's
> child came from the rel's partial_pathlist, and the only way it gets
> used from there is to stick the Gather on top of it.  So it really
> can't show up anywhere else.  I think.

The key question I think is could there ever be more than one Gather
sharing the same subpath?

> (To some lesser extent, apply_projection_to_path is always
> scary like that.)

Right, that's why there's also create_projection_path for when you
aren't sure.

> Mmmph.  That seems like a 2-bit solution, but I guess it would work.
> What if we taught create_projection_plan() to elide the Result node in
> that case?

Yeah, I was thinking about the same thing.  The comment block above
where you're looking would need some adjustment.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Choosing parallel_degree
Next
From: Pavel Stehule
Date:
Subject: Re: Idle In Transaction Session Timeout, revived