Re: Partition pruning can incorrectly exclude a RANGE default partition

David Rowley <dgrowleyml(at)gmail(dot)com> 于2026年7月30日周四 11:47写道：
> (Much of this has been said already, but I wanted to summarise my
> independent analysis)

Thanks for the detailed write-up. Your analysis is very thorough, and
I think it accurately captures the root cause of this issue.

>
> I see a couple of ways to fix this:
>
> 1. Modify PartitionBoundInfoData to add a new Bitmapset which marks
> which of the indexes[] array maps to -1. Then in
> get_matching_range_bounds(), once we've set bound_offsets, check if we
> have a bms_overlap with the new Bitmapset and set scan_default=true if
> there is; or
> 2. Modify get_matching_range_bounds() so that we mark *all*
> bound_offsets for the "if (nvalues == 0)" path.
>
> #1 is more invasive as it requires a new field in
> PartitionBoundInfoData, then some extra processing when we execute
> each RANGE pruning step. This can happen often for run-time pruning
> and this might slow down that enough to notice.
>

Initially, I tried to pursue approach #1 for the fix. However, as I
dug deeper, I found that it required changes in many places, as you
pointed out.

> In other words, I think #2 is the correct fix. The attached v1-0001
> patchifies that method.
>
> Another alternative fix would be to modify the
> PARTPRUNE_COMBINE_INTERSECT code to special-case RANGE partitioned
> tables to check for any bound_offsets that map to the default
> partition and set scan_default=true when it finds some. I don't like
> this method as that code is currently unaware of different
> partitioning methods and to fix it this way would mean adding a
> special case for RANGE partitioned tables.
>

Yes, I agree that #2 is the better approach. It is simpler, more
straightforward, and has less impact on the existing code.

--
Thanks,
Tender Wang