From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Clarify nbtree array exhaustion comments. |
Date: | 2024-10-30 17:44:04 |
Message-ID: | E1t6Cjl-003B9O-9m@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Clarify nbtree array exhaustion comments.
Strictly speaking, we only need to make sure to leave the scan's array
keys in their final positions (final for the current scan direction) to
handle SAOP array exhaustion because btgettuple might only return a
subset of the items for the final page (final for the current scan
direction), before the scan changes direction. While it's typical for
so->currPos to be invalidated shortly after the scan's arrays are first
exhausted, and while so->currPos invalidation does obviate the need to
leave the scan's arrays in any particular state, we can't rely on any of
that actually happening when handling array exhaustion. Adjust comments
to make all of that a lot clearer.
Oversight in commit 5bf748b8, which enhanced nbtree ScalarArrayOp
execution.
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/81a25790f1f66319b4f088148b97dbb8badd4907
Modified Files
--------------
src/backend/access/nbtree/nbtutils.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2024-10-30 19:53:41 | pgsql: nbtree: assert no scheduled primscan between pages. |
Previous Message | Nathan Bossart | 2024-10-30 16:29:12 | pgsql: Optimize sifting down in binaryheap. |