On Tue, 30 Sept 2025 at 02:49, Lauro Ojeda <[email protected]> wrote: > By looking into it, I have the impression there is a bug in the costing sum > in that situation, where the cost of the "never executed" partitions should > be deducted from the final cost estimation, which would make pruning to be > the preferred option in this case. > > Are my assumptions correct?
The "never executed" part is not determined at planning time. It's only something the executor gets to figure out, and by that time, it's no good adjusting the plan's costs since the planner has already decided on what it thinks the best plan is and it's too late to change that. > Is there anything I could do to influence the planner to dismiss the cost of > "never executed" scans? Not in the general sense, but for nodes that are "never executed" due to run-time partition pruning. It would be possible to make some assumptions during planning. The planner would need to do some extra work during planning to figure out if an AppendPath or MergeAppend path has run-time prunable parameters. If those parameters plus any non-parameterized quals result in pruning being possible at run-time, then *maybe* there's something we can do better. For equi joins, you could assume that only 1 of the Append children will be scanned. The planner will have no idea which one, but it could do something like total_append_cost / number_of_append_children. For other join types, it's much less clear how that would work. There have been previous proposals to do something with DEFAULT_INEQ_SEL or maybe DEFAULT_RANGE_INEQ_SEL. I've forgotten the exact details as it was about 8 years ago. David
