Re: Parallelize correlated subqueries that execute within each worker - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Parallelize correlated subqueries that execute within each worker
Date
Msg-id 8701.1635952475@sss.pgh.pa.us
Whole thread Raw
In response to Re: Parallelize correlated subqueries that execute within each worker  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Parallelize correlated subqueries that execute within each worker
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> When I last worked on this, I had hoped that extParam or allParam
> would be the thing that would answer the question: are there any
> parameters used under this node that are not also set under this node?
> But I seem to recall that neither seemed to be answering precisely
> that question, and the lousy naming of those fields and limited
> documentation of their intended purpose did not help.

FWIW, I've never been very happy with those fields either.  IIRC the
design in that area was all Vadim's, but to the extent that there's
any usable documentation of extParam/allParam, it was filled in by me
while trying to understand what Vadim did.  If somebody wants to step
up and do a rewrite to make the planner's Param management more useful
or at least easier to understand, I think that'd be great.

But anyway: yeah, those fields as currently constituted don't help
much.  They tell you which Params are consumed by this node or its
subnodes, but not where those Params came from.  The planner's
plan_params and outer_params fields might be more nearly the right
thing, but I'm not sure they're spot-on either, nor that they're
up-to-date at the point where you'd want to make decisions about
Gather safety.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: remove internal support in pgcrypto?
Next
From: Tomas Vondra
Date:
Subject: Re: GiST operator class for bool