On Thu, Oct 22, 2015 at 2:49 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Oct 22, 2015 at 1:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Um ... why would you not want the projections to happen in the child
>> nodes, where they could be parallelized? Or am I missing something?
>
> 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).
And here's a (rather small) patch to push target-list evaluation down
to the worker whenever possible. With this, if you do something like
...
SELECT aid + bid FROM pgbench_accounts WHERE aid % 10000 = 0;
...then aid + bid can be calculated in the workers rather than in the
leader. Unfortunately, if you do this...
SELECT sum(aid + bid) FROM pgbench_accounts WHERE aid % 10000 = 0;
...then it doesn't help, because make_subplanTargetList() thinks it
may as well just pull aid and bid out of the join nest and then do the
sum during the aggregation stage. Presumably if we get the parallel
aggregation stuff working then this will get fixed, because there will
be a Partial Aggregate step before the Gather. But whether that gets
into 9.6 or not, this seems like a useful step forward.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company