Robert forwarded me a link to an email sent to -general list, where the reported problem seems to be the same problem that was being discussed here.
https://www.postgresql.org/message-id/flat/d0f6d811-8946-eb9f-68e2-1a8a7f80ff21%40a-kretschmer.de Going over the last few emails, it seems that David held off from committing the patch, because of the lack of confidence in its robustness. With the patch, a sub-partitioned child's partial Append's child paths will *always* be pulled up into the parent's set of partial child paths thus preventing the nesting of Appends, which the run-time pruning code can't currently cope with. The lack of confidence seems to be due to the fact that always pulling up a sub-Append's child paths into the parent partial Append's child paths *may* cause the latter to behave wrongly under parallelism and the new code structure will prevent add_partial_path() from being the arbitrator of whether such a path is really the best in terms of cost. If we can't be confident in that approach, maybe we should consider making the run-time pruning code cope with nested Appends? -- Amit Langote EDB: http://www.enterprisedb.com
