On Wed, 26 Aug 2026 at 02:24, Ayush Tiwari <[email protected]> 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
