Re: Parallelize correlated subqueries that execute within each worker

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Parallelize correlated subqueries that execute within each worker
Дата
Msg-id 134557.1635958336@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Parallelize correlated subqueries that execute within each worker  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> One thing I discovered when I was looking at this a few years ago is
> that there was only one query in the regression tests where extParam
> and allParam were not the same. The offending query was select 1 =
> all(select (select 1)), and the resulting plan has a Materialize node
> with an attached InitPlan. For that Materialize node, extParam = {}
> and allParam = {$0}, with $0 also being the output parameter of the
> InitPlan attached that that Materialize node. In every other node in
> that plan and in every node of every other plan generated by the
> regression tests, the values were identical. So it's extremely niche
> that these fields are even different from each other, and it's unclear
> to me that we really need both of them.

Yeah, I've had that nagging feeling about them too.  But ISTR trying to
reduce them to one value years ago, and finding that it didn't quite work,
or at least would result in more subquery-re-evaluation than we do today.
You have to dig into what the executor uses these values for to really
grok them.  I'm afraid that that detail is all swapped out right now, so
I can't say much more.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Parallelize correlated subqueries that execute within each worker
Следующее
От: "Daniel Westermann (DWE)"
Дата:
Сообщение: Perl warnings when building contrib on RHEL 9 beta