On Wed, Mar 16, 2016 at 3:09 AM, Amit Kapila <amit.kapil...@gmail.com>
wrote:
> 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.
>
That doesn't update the cost of the subpath, which it probably needs to
do. I wonder if this shouldn't be implemented by recursing.
if (IsA(path, GatherPath) && !has_parallel_hazard((Node *) target->exprs,
false))
apply_projection_to_path(root, something, ((GatherPath *)
path)->subpath, target);
Tom, any comments? I think it would be smart to push this into 9.6.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
