Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90
Date
Msg-id 16978.1503946802@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] [BUGS] [postgresql 10 beta3] unrecognized node type: 90
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Custom allocators in libpq