Re: Saving stack space in nbtree's _bt_first function

2025-07-16 Thread Peter Geoghegan
On Wed, Jul 16, 2025 at 9:17 AM Mircea Cadariu wrote: > 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. Pushed.

Re: Saving stack space in nbtree's _bt_first function

2025-07-16 Thread Mircea Cadariu
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/BTLes

Re: Saving stack space in nbtree's _bt_first function

2025-07-15 Thread Peter Geoghegan
On Tue, Jul 15, 2025 at 4:50 PM Mircea Cadariu wrote: > As an experiment, I added an elog(WARNING,...) just above the main changed > line in the patch, and then ran the tests (make installcheck). This resulted > in lines logged next to some of the SELECT statements in the following files > in s

Re: Saving stack space in nbtree's _bt_first function

2025-07-15 Thread Mircea Cadariu
Hi, On 07/07/2025 01:22, Peter Geoghegan wrote: However, there's no reason why "ScanKeyData notnullkeys[INDEX_MAX_KEYS]" needs to be an array at all. In practice, _bt_first will only need a single temp notnullkeys ScanKeyData, since there can never be more than a single deduced NOT NULL constrai