Re: generic plans and "initial" pruning - Mailing list pgsql-hackers

From Tom Lane
Subject Re: generic plans and "initial" pruning
Date
Msg-id 813399.1691423093@sss.pgh.pa.us
Whole thread Raw
In response to Re: generic plans and "initial" pruning  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: generic plans and "initial" pruning
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Second, I wondered whether the ordering of cleanup operations could be
> an issue. Right now, a node can position cleanup code before, after,
> or both before and after recursing to child nodes, whereas with this
> design change, the cleanup code will always be run before recursing to
> child nodes. Here, I think we have problems. Both ExecGather and
> ExecEndGatherMerge intentionally clean up the children before the
> parent, so that the child shutdown happens before
> ExecParallelCleanup(). Based on the comment and commit
> acf555bc53acb589b5a2827e65d655fa8c9adee0, this appears to be
> intentional, and you can sort of see why from looking at the stuff
> that happens in ExecParallelCleanup().

Right, I doubt that changing that is going to work out well.
Hash joins might have issues with it too.

Could it work to make the patch force child cleanup before parent,
instead of after?  Or would that break other places?

On the whole though I think it's probably a good idea to leave
parent nodes in control of the timing, so I kind of side with
your later comment about whether we want to change this at all.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: generic plans and "initial" pruning
Next
From: Robert Haas
Date:
Subject: Re: initial pruning in parallel append