Re: Parallelize correlated subqueries that execute within each worker

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Parallelize correlated subqueries that execute within each worker
Дата
Msg-id 8701.1635952475@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Parallelize correlated subqueries that execute within each worker  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Parallelize correlated subqueries that execute within each worker  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: remove internal support in pgcrypto?
Следующее
От: Tomas Vondra
Дата:
Сообщение: Re: GiST operator class for bool