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

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

I can't recreate this. Are you sure you tested with partition pruning enabled?

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

David