From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: make Gather node projection-capable |
Date: | 2015-10-24 00:29:03 |
Message-ID: | CA+Tgmoai9Ruhwk61110rY4cNAzoO6npsFEOaEKjM7Zz8i3evHg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 22, 2015 at 2:49 PM, Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2015-10-24 01:22:16 | Re: Parallel Seq Scan |
Previous Message | Jeff Janes | 2015-10-24 00:11:32 | Re: 9.5Beta1 psql wrapped format expanded output |