On Fri, Aug 17, 2018 at 2:58 AM, David Rowley
<david.row...@2ndquadrant.com> wrote:
>> I'm baffled as to why looking through Gather to find
>> Append/MergeAppend subpaths would ever be a sane thing to do.
>
> Can you explain why it's less sane than what the current code is
> doing? Below a Gather there will be partial paths, but we can also
> get those in a Parallel Append, which the accumulate_append_subpath()
> code already attempts to handle.
Sorry, I lost track of this email. accumulate_append_subpath's job is
to flatten stacked Append nodes into a single Append node. But you
can't in general flatten two Append nodes that are separated by
something else in the middle, because that other node probably does
something. To take a really simple example, consider:
Append
-> Result
-> Append
-> ...
-> ...
Well, the Result node computes a new target list, so the inner Append
node can't just blindly be combined with the outer Append node. You
might be able to make it work if you adjusted the inner Append node's
children to produce the same target list that the Result node
produces, but you can't just flatten it blindly.
The same thing is true of Gather:
Append
-> Gather
-> Append
-> ...
-> ...
The child paths of the inner Append node are known to be parallel-safe
and are necessarily partial paths unless the inner Append is a
Parallel Append; the paths under the outer Append are definitely not
partial and might not even be parallel-safe (they can't be
parallel-unsafe, or we couldn't have a Gather anywhere in the plan,
but they *could* be parallel-restricted). If you tried to flatten the
inner Append into the outer one, you'd no longer have anything like a
valid plan, because you can't have a partial path anywhere in the tree
without a Gather someplace higher up, which wouldn't be true here any
more, which I guess is what you meant by ...
> If the Gather Path is there already
> then I guess one difference would be that the caller would need to
> ensure that another Gather path is placed below the Parallel Append
> again.
...this, but that's not right. The Gather would have to go ABOVE the
Parallel Append.
The broader point here, though, is that even if you could do this kind
of surgery, it's the wrong way of going about the problem. In any
case where Append-Gather-Append could be flattened to Gather-Append,
we should have just generated Gather-Append initially, rather than
trying to rejigger things that way later. And I think that's what the
code does. I'm not sure exactly what's going wrong with runtime
partition pruning in this case, but ISTM that if runtime partition
pruning doesn't work in some obscure case, that's just a limitation we
should accept until somebody gets around to working on it. The key
thing right now is not to have crashes or wrong behavior, so that we
can ship.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
