On Wed, 26 Aug 2026 at 23:09, David Rowley <[email protected]> wrote: > > On Wed, 26 Aug 2026 at 02:24, Ayush Tiwari <[email protected]> > wrote: > > Should the check use the actual array bounds instead? > > > > if (nextoff < 0 || nextoff >= boundinfo->ndatums) > > I modified the fuzzer tool to record the plans of each query tested, > and it seems that not visiting the end elements could result in > partitions *not* being pruned that could be pruned, so making that the > condition seems correct. > > > Would the same apply to the similar loop in the > > BTGreaterStrategyNumber case? > > The fuzzer highlighted that that's the case with this one too. More > partitions could be pruned that are not pruned today.
I've attached the updated patch and the updated fuzzer tool, which has some hand-modified adjustments made to record the plans. I did the following: truncate pp_fuzz.debug_output; CALL pp_fuzz.run(iterations := 10000, seed := 12341); \o somefile.txt select line from pp_fuzz.debug_output order by id; Then made the code adjustments and ran the same again into another output file and compared with my diff tool. The first difference it highlighted was a greater-than query that didn't prune one partition that it could have. I included that as a regression test. David
partprune_fuzz.sql
Description: Binary data
v2-0001-Fix-incorrect-multi-column-RANGE-partition-prunin.patch
Description: Binary data
