On Thu, 15 Oct 2020 at 03:53, Andreas Kretschmer <andreas@xxxxxxxxxxxxxxx> wrote: > it seems to me a bug. i have a partitioned table: I've just pushed a fix [1] for this to master only (PG14+) The problem was that we only added the required information to allow the executor to perform run-time pruning to the Append/MergeAppend for the top-level Append. The example you've given actually did have a nested-Append at one point during planning. However, since the top-level Append only had a single sub-plan, it was removed and that single sub-plan was used instead. Since that single sub-plan happened to be an Append, there was no run-time pruning information to allow the executor to prune away the unneeded partitions. The fix for this was a bit too invasive to go backpatching it. Run-time pruning was coded purposefully to only prune on the top-level Append/Merge Append. In hindsight, that was likely a bad choice, but it was the choice that was made originally, so I'm leaning towards not classing this as a bug. After thinking about this all over again, it seems there are more legitimate reasons to have nested Append/Merge Appends than I had thought when I was originally working on run-time pruning, so it makes sense to allow run-time pruning on those to work going forward. Thanks for the report. David [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=a929e17e5a8c9b751b66002c8a89fdebdacfe194
