Hi, On Tue, 25 Aug 2026 at 16:32, David Rowley <[email protected]> wrote:
> There is still a pending bug report in [1] about the DEFAULT partition > still being pruned incorrectly in some cases. This one isn't the same > issue, but I did find this one as a result of looking into Ewan's > report (which I'm still looking at). > > This is the reproducer: > > create table mc2ap (a int, b int) partition by range (a, b); > create table mc2ap1 partition of mc2ap for values from (1, 4) to (1, 7); > create table mc2ap2 partition of mc2ap for values from (1, 7) to (3, 8); > create table mc2ap3 partition of mc2ap for values from (4, 8) to (6, 9); > create table mc2ap_def partition of mc2ap default; > > insert into mc2ap values(1,7); > > explain select * from mc2ap where a <= 1; > > set enable_partition_pruning=1; > select * from mc2ap where a <= 1; -- 0 rows (!) > set enable_partition_pruning=0; > select * from mc2ap where a <= 1; -- 1 row > > mc2ap2 gets pruned by mistake due to an incorrectly coded loop bound. > In this scenario, before the loop, off == 0, so we never perform any > loops to look for other matching bounds. I've moved the condition > check for the loop until after nextoff has been set (according to the > inclusive variable) and breaking out the loop if nextoff is out of > bounds. > I tested v1 and it fixes the reported wrong-result case. Using the same partition layout, I also tried: EXPLAIN (COSTS OFF) SELECT * FROM mc2ap WHERE a < 1; Master scans only mc2ap_def, while v1 scans both mc2ap1 and mc2ap_def. The result is unchanged, but it seems that the new check rejects nextoff == 0 even though that is a valid index into boundinfo->datums. Should the check use the actual array bounds instead? if (nextoff < 0 || nextoff >= boundinfo->ndatums) Would the same apply to the similar loop in the BTGreaterStrategyNumber case? Regards, Ayush
