Re: More partition pruning bugs with multi-column RANGE partitions

On Wed, 26 Aug 2026 at 23:09, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Wed, 26 Aug 2026 at 02:24, Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> 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