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

Hi,

On Tue, 25 Aug 2026 at 16:32, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

> There is still a pending bug report in [1] about the DEFAULT partition
> still being pruned incorrectly in some cases. This one isn't the same
> issue, but I did find this one as a result of looking into Ewan's
> report (which I'm still looking at).
>
> This is the reproducer:
>
> create table mc2ap (a int, b int) partition by range (a, b);
> create table mc2ap1 partition of mc2ap for values from (1, 4) to (1, 7);
> create table mc2ap2 partition of mc2ap for values from (1, 7) to (3, 8);
> create table mc2ap3 partition of mc2ap for values from (4, 8) to (6, 9);
> create table mc2ap_def partition of mc2ap default;
>
> insert into mc2ap values(1,7);
>
> explain select * from mc2ap where a <= 1;
>
> set enable_partition_pruning=1;
> select * from mc2ap where a <= 1; -- 0 rows (!)
> set enable_partition_pruning=0;
> select * from mc2ap where a <= 1; -- 1 row
>
> mc2ap2 gets pruned by mistake due to an incorrectly coded loop bound.
> In this scenario, before the loop, off == 0, so we never perform any
> loops to look for other matching bounds. I've moved the condition
> check for the loop until after nextoff has been set (according to the
> inclusive variable) and breaking out the loop if nextoff is out of
> bounds.
>

I tested v1 and it fixes the reported wrong-result case.

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.

Should the check use the actual array bounds instead?

if (nextoff < 0 || nextoff >= boundinfo->ndatums)

Would the same apply to the similar loop in the
BTGreaterStrategyNumber case?

Regards,
Ayush