David Rowley <[email protected]> 于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
