On Wed, Mar 9, 2016 at 11:58 PM, Robert Haas <robertmh...@gmail.com> wrote: > > On Wed, Mar 9, 2016 at 12:33 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > > > Gather is a bit weird, because although it can project (and needs to, > > per the example of needing to compute a non-parallel-safe function), > > you would rather push down as much work as possible to the child node; > > and doing so is semantically OK for parallel-safe functions. (Pushing > > functions down past a Sort node, for a counterexample, is not so OK > > if you are concerned about function evaluation order, or even number > > of executions.) > > > > In the current code structure it would perhaps be reasonable to teach > > apply_projection_to_path about that --- although this would require > > logic to separate parallel-safe and non-parallel-safe subexpressions, > > which doesn't quite seem like something apply_projection_to_path > > should be doing. > > I think for v1 it would be fine to make this all-or-nothing; that's > what I had in mind to do. That is, if the entire tlist is > parallel-safe, push it all down. If not, let the workers just return > the necessary Vars and have Gather compute the final tlist. >
I find it quite convenient to teach apply_projection_to_path() to push down
target-list beneath Gather node, when targetlist contains parallel-safe
expression. Attached patch implements pushing targetlist beneath gather
node.
Below is output of a simple test which shows the effect of implementation.
Without Patch -
------------------------
postgres=# explain verbose select c1+2 from t1 where c1<10;
QUERY PLAN
-----------------------------------------------------------------------------
Gather (cost=0.00..44420.43 rows=30 width=4)
Output: (c1 + 2)
Number of Workers: 2
-> Parallel Seq Scan on public.t1 (cost=0.00..44420.35 rows=13 width=4)
Output: c1
Filter: (t1.c1 < 10)
(6 rows)
With Patch -
-----------------------
postgres=# explain verbose select c1+2 from t1 where c1<10;
QUERY PLAN
-----------------------------------------------------------------------------
Gather (cost=0.00..45063.75 rows=30 width=4)
Output: ((c1 + 2))
Number of Workers: 1
-> Parallel Seq Scan on public.t1 (cost=0.00..45063.68 rows=18 width=4)
Output: (c1 + 2)
Filter: (t1.c1 < 10)
(6 rows)
In the above plans, you can notice that target list expression (c1 + 2) is
pushed beneath Gather node after patch.
Thoughts?
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
parallel-tlist-pushdown-v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
