diff options
| author | Peter Geoghegan <pg@bowt.ie> | 2025-07-16 13:05:44 -0400 |
|---|---|---|
| committer | Peter Geoghegan <pg@bowt.ie> | 2025-07-16 13:05:44 -0400 |
| commit | 4c8ad67a98b5d84c1ca00a26d53d08f2d2b881aa (patch) | |
| tree | 2b58a3eef80132b9611ca1cfd205b84bdce4595a /src/test/modules/test_regex/test_regex.control | |
| parent | 48c2c7b4b45b3bb696d566f4f425fccdd871532f (diff) | |
| download | postgresql-4c8ad67a98b5d84c1ca00a26d53d08f2d2b881aa.tar.gz postgresql-4c8ad67a98b5d84c1ca00a26d53d08f2d2b881aa.zip | |
nbtree: Use only one notnullkey ScanKeyData.
_bt_first need only store one ScanKeyData struct on the stack for the
purposes of building an IS NOT NULL key based on an implied NOT NULL
constraint. We don't need INDEX_MAX_KEYS-many ScanKeyData structs.
This saves us a little over 2KB in stack space. It's possible that this
has some performance benefit. It also seems simpler and more direct.
It isn't possible for more than a single index attribute to need its own
implied IS NOT NULL key: the first such attribute/IS NOT NULL key always
makes _bt_first stop adding additional boundary keys to startKeys[].
Using INDEX_MAX_KEYS-many ScanKeyData entries was (at best) misleading.
Author: Peter Geoghegan <pg@bowt.ie>
Reviewed-By: Mircea Cadariu <cadariu.mircea@gmail.com>
Discussion: https://postgr.es/m/CAH2-Wzm=1kJMSZhhTLoM5BPbwQNWxUj-ynOEh=89ptDZAVgauw@mail.gmail.com
Diffstat (limited to 'src/test/modules/test_regex/test_regex.control')
0 files changed, 0 insertions, 0 deletions