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