Hi, On Wed, 26 Aug 2026 at 18:11, David Rowley <[email protected]> wrote:
> 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. > Sorry, you're right. I had used a slightly different partition layout for that test and mistakenly said it was the same layout. 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. > Thanks for updating both loops. The v2 patch looks good to me. Regards, Ayush
