Re: Saving stack space in nbtree's _bt_first function

On 16/07/2025 07:27, Peter Geoghegan wrote:

> [...] Rather, we rely on the generic logic that
> builds our startKeys[] entries. It will inevitably "break" before ever
> moving on to the next index attribute/next so->keyData[] key because
> strat_total will inevitably become
> BTGreaterStrategyNumber/BTLessStrategyNumber. In other words, the
> generic BTGreaterStrategyNumber/BTLessStrategyNumber test will
> inevitably cause the loop to "break" right after our first (and only)
> use of notnullkey.

Thanks for the elaboration and updated patch! Indeed, I see it's set in
the ScanKeyEntryInitialize to either BTGreaterStrategyNumber or
BTLessStrategyNumber, then few lines lower there's the if with the break.

I'm convinced.

I noticed this CI job failure for the V2, seems unrelated to the subject
of the patch though, does it need a retry?
https://cirrus-ci.com/task/5781246762024960

Kind regards,

Mircea Cadariu