On Thu, Oct 22, 2015 at 2:49 PM, Robert Haas <robertmh...@gmail.com> wrote: > You probably would, but sometimes that might not be possible; for > example, the tlist might contain a parallel-restricted function (which > therefore has to run in the leader).
Oh, also: pushing down the tlist is actually sorta non-trivial at the moment. I can stick a GatherPath on top of whatever the join planner kicks out (although I don't have a cost model for this yet, so right now it's just a hard-coded test), but the upper planner substitutes the tlist into whatever the topmost plan node is - and that's the Gather, not whatever's under it. Maybe I should have a special case for this: if the node into which we would insert the final tlist is a Gather, see whether it's parallel-safe, and if so, peel the Gather node off, apply the tlist to whatever's left (adding a gating Result node if need be) and put the Gather back on. This seems less important than a few other things I need to get done, but certainly worth doing. But do you know whether the upper planner path-ifaction work will be likely to render whatever code I might write here obsolete? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
