Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90
Дата
Msg-id 16978.1503946802@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Aug 28, 2017 at 10:47 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> - fuller description.  Academic literature on parallel query suggests that
> + fuller description.  The academic literature on parallel query suggests

> That sentence isn't wrong as written.

Count the "that"s (you're failing to notice the next line).

> I don't really understand the part about depending on a parallel-aware
> node.  I mean, there should always be one, except in the
> single-copy-Gather case, but why is it right to depend on that rather
> than anything else?  What happens when the Parallel Hash patch goes in
> and we have multiple parallel-aware scan nodes (plus a parallel-aware
> Hash node) under the same Gather?

Well, that's what I'm asking.  AFAICS we only really need the scan node(s)
to be marked as depending on the Gather's rescan parameter.  It would not,
however, hurt anything for nodes above them to be so marked as well ---
and even if we didn't explicitly mark them, those nodes would end up
depending on the parameter anyway because of the way that parameter
dependency propagation works.  I think the question boils down to whether
a "parallel_aware" node would ever not be underneath a related Gather.
        regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Custom allocators in libpq