Re: make Gather node projection-capable

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

In response to

Browse pgsql-hackers by date

  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