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

Hi,

On Wed, 26 Aug 2026 at 18:11, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

> 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.
>

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