(just catching up on this thread) On Thu, 13 Jan 2022 at 07:20, Robert Haas <robertmh...@gmail.com> wrote: > Yeah. I don't think it's only non-core code we need to worry about > either. What if I just do EXPLAIN ANALYZE on a prepared query that > ends up pruning away some stuff? IIRC, the pruned subplans are not > shown, so we might escape disaster here, but FWIW if I'd committed > that code I would have pushed hard for showing those and saying "(not > executed)" .... so it's not too crazy to imagine a world in which > things work that way.
FWIW, that would remove the whole point in init run-time pruning. The reason I made two phases of run-time pruning was so that we could get away from having the init plan overhead of nodes we'll never need to scan. If we wanted to show the (never executed) scans in EXPLAIN then we'd need to do the init plan part and allocate all that memory needlessly. Imagine a hash partitioned table on "id" with 1000 partitions. The user does: PREPARE q1 (INT) AS SELECT * FROM parttab WHERE id = $1; EXECUTE q1(123); Assuming a generic plan, if we didn't have init pruning then we have to build a plan containing the scans for all 1000 partitions. There's significant overhead to that compared to just locking the partitions, and initialising 1 scan. If it worked this way then we'd be even further from Amit's goal of reducing the overhead of starting plan with run-time pruning nodes. I understood at the time it was just the EXPLAIN output that you had concerns with. I thought that was just around the lack of any display of the condition we used for pruning. David