Thread

  1. Re: Saving stack space in nbtree's _bt_first function

    Mircea Cadariu <cadariu.mircea@gmail.com> — 2025-07-16T13:16:58Z

    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