David Rowley <david.row...@2ndquadrant.com> writes: >> It's probably best discussed on the other thread, but it seems to be >> by design in accumulate_append_subpath(). Parallel Append nodes don't >> get flattened if they contain a mix of parallel aware and non-parallel >> aware subplans.
I don't really understand the issue at hand, but let me just make a comment about accumulate_append_subpath(). If we have a regular Append on top of another regular Append or on top of a MergeAppend, we can flatten the lower Merge(Append) into the upper one. No problem. If, however, the lower path is a Parallel Append, we can't. Consider this plan: Gather -> Append -> Partial Subpath #1 -> Parallel Append -> Partial Subpath #2 -> Non-partial Subpath Making Partial Subpath #2 a child of the Append rather than the Parallel Append would be correct; the only downside is that we'd lose the nice worker-balancing stuff that the Parallel Append does. However, making Non-partial Subpath a child of the Append rather than the Parallel Append would be dead wrong, because the Parallel Append will make sure that it only gets executed by one of the cooperating processes, and the regular Append won't. If the upper Append were changed to a Parallel Append, then we could flatten the whole thing just fine, as long as we're careful to keep partial paths and non-partial paths separated. Also, if the situation is reversed, with an upper Parallel Append and a regular Append beneath it, that's always flatten-able. > Yeah, looking at the explain posted upthread, the issue is specifically > that some of the child paths might be for Gathers over subsets of the > partitioning hierarchy. It's not real clear to me whether such a subset > would necessarily correspond to a subtree of the hierarchy, but if it > does, you'd want to be able to apply run-time pruning at the parent > Append, in hopes of not having to execute the Gather at all. Separately > from that, if you do execute the Gather, applying runtime pruning within > its child Append is also a good thing. That sounds right to me. If I'm not mistaken, in that EXPLAIN, the radicado2012 and radicado2017 partitions are ineligible for parallel query for some reason, maybe a reloption setting, but the other partitions are all eligible, or rather, their subpartitions are eligible. If they were all OK for parallel query, the plan would probably just end up with Gather over Parallel Append over individual sample scans. In general, I think the only ways to get an Append are inheritance, partitioning, and set operations. If an upper Append is due to partitioning or inheritance, then I think that any (Merge)Append nodes beneath it must be a subtree of the partitioning or inheritance hierarchy, respectively. Partitioning and inheritance can't be mixed, and set operations can't occur below partition expansion. However, if the upper Append was created by a set operation, then its child Append nodes could be from any of those causes. For instance, it seems possible to imagine an upper Append that is implementing EXCEPT and a lower Append that is implementing both partition expansion and UNION ALL. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company