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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Aug 28, 2017 at 3:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Count the "that"s (you're failing to notice the next line).

> OK, true. But "Academic literature" -> "The academic literature" is
> just second-guessing, I think.

No, it was more to avoid reflowing the paragraph (or leaving a weirdly
short line).

> There should never be a parallel_aware node that's not beneath a
> Gather or Gather Merge; I don't know what the meaning of such a plan
> would be, so I think we're safe against such a thing appearing in the
> future. What I'm unclear about is what happens with nodes that aren't
> directly in the chain between the Gather and the parallel-aware node.

Nothing. The parallel-aware node(s) get marked as dependent on the rescan
parameter, and then that marking bubbles up to their ancestor nodes (up
to the Gather). Nodes that are not ancestral to any parallel-aware node
are unchanged.

> Now consider Parallel Hash
> (not yet committed), where we might get this:

> Something
> -> Gather
> -> Merge Join
> -> Sort
> -> Parallel Seq Scan on a
> -> Hash Join
> -> Index Scan on b
> -> Parallel Hash
> -> Parallel Seq Scan on c

> Now what? We clearly still need to force a re-sort of a, but what
> about the shared hash table built on c? If we've still got that hash
> table and it was a single-batch join, there's probably no need to
> rescan it even though both the Parallel Hash node and the Parallel Seq
> Scan beneath it are parallel-aware. In this case all workers
> collaborated to build a shared hash table covering all rows from c; if
> we've still got that, it's still good. In fact, even the workers can
> reuse that hash table even though, for them, it'll not really be a
> re-scan at all.

Well, I'd say that's something for the parallel hash patch to resolve.
Yes, if the contents of the hash table are expected to be the same
regardless of how many workers were involved, then we shouldn't need
to rebuild it after a rescan of the Gather. That would mean not marking
either Parallel Hash or its descendant Parallel Seq Scan as dependent
on the Gather's rescan param. That's not terribly hard to mechanize
within the structure of this patch: just ignore the param at/below
the ParallelHash. Cowboy coding would be, perhaps,

if (plan->parallel_aware)
{
if (gather_param < 0)
elog(ERROR, "parallel-aware plan node is not below a Gather");
+ if (IsA(plan, Hash))
+ gather_param = -1;
+ else
context.paramids =
bms_add_member(context.paramids, gather_param);
}

but probably we should think of a more arm's-length way to do it.
Maybe parallel_aware should have more than two values, depending
on whether the result of the node is context-dependent or not.

regards, tom lane