On 04/03/2018 10:10 PM, David Rowley wrote:
The attached case doesn't trigger a generic plan, so basically all time is
spent in GetCachedPlan.
Yeah, there's still no resolution to the fact that a generic plan +
runtime pruning might be cheaper than a custom plan. The problem is
the generic plan appears expensive to the custom vs generic plan
comparison due to it containing more Append subnodes and the run-time
pruning not being taking into account by that comparison.
There's been some discussion about this on this thread somewhere.
Forgot about that, sorry.
I think the best solution is probably the one suggested by Robert 
and that's to alter the Append plan's cost when run-time pruning is
enabled to try to account for the run-time pruning. This would be a
bit of a blind guess akin to what we do for clause selectivity
estimates for Params, but it's probably better than nothing, and
likely better than doing nothing.
Yeah, something based on the number of WHERE clauses, and if the
partition type has DEFAULT / NULL partition could help. Forcing
choose_custom_plan() to return false does help a lot (> 400%) for the
But maybe this area is best left for PG12.
Yeah, it's a bug in v46 faster partition pruning. Discussing a fix for
that with Amit over on .
I was running with a version of faster_part_prune_v45_fixups.patch.
Patch v49 with v18 (0001-0004) works. 0005 needs a rebase.