Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitc902bd5

Browse files
Update obsolete row compare preprocessing comments.
We have some limited ability to detect redundant and contradictoryconditions involving an nbtree row comparison key following commitsf09816a andbd3f59f: we can do so in simple cases involving IS NULLand IS NOT NULL keys on a row compare key's first column. We canlikewise determine that a scan's qual is unsatisfiable given a rowcompare whose first subkey's arg is NULL. Update obsolete comments thatclaimed that we merely copied row compares into the output key array"without any editorialization".Also update another _bt_preprocess_keys header comment paragraph: add aparenthetical remark that points out that preprocessing will generate askip array for the preceding example qual. That will ultimate lead topreprocessing marking the example's lower-order y key required -- whichis exactly what the example supposes cannot happen. Keep the originalcomment, though, since it accurately describes the mechanical rules thatdetermine which keys get marked required in the absence of skip arrays(which can occasionally still matter). This fixes an oversight incommit92fe23d, which added the nbtree skip scan optimization.Author: Peter Geoghegan <pg@bowt.ie>Backpatch-through: 18
1 parent3881561 commitc902bd5

File tree

1 file changed

+16
-7
lines changed

1 file changed

+16
-7
lines changed

‎src/backend/access/nbtree/nbtpreprocesskeys.c‎

Lines changed: 16 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -122,6 +122,10 @@ static int_bt_compare_array_elements(const void *a, const void *b, void *arg);
122122
* For the first attribute without an "=" key, any "<" and "<=" keys are
123123
* marked SK_BT_REQFWD while any ">" and ">=" keys are marked SK_BT_REQBKWD.
124124
* This can be seen to be correct by considering the above example.
125+
* (Actually, the z key _will_ be marked SK_BT_REQFWD, since preprocessing
126+
* will generate a skip array on y -- except when DEBUG_DISABLE_SKIP_SCAN.
127+
* See below description of how and why we generate skip array = keys in the
128+
* presence of a "contradictory" condition such as "y < 4".)
125129
*
126130
* If we never generated skip array scan keys, it would be possible for "gaps"
127131
* to appear that make it unsafe to mark any subsequent input scan keys
@@ -177,13 +181,18 @@ static int_bt_compare_array_elements(const void *a, const void *b, void *arg);
177181
* array will generate its array elements from a range that's constrained by
178182
* any merged input inequalities (which won't get output in so->keyData[]).
179183
*
180-
* Row comparison keys currently have a couple of notable limitations.
181-
* Right now we just transfer them into the preprocessed array without any
182-
* editorialization. We can treat them the same as an ordinary inequality
183-
* comparison on the row's first index column, for the purposes of the logic
184-
* about required keys. Also, we are unable to merge a row comparison key
185-
* into a skip array (only ordinary inequalities are merged). A key that
186-
* comes after a Row comparison key is therefore never marked as required.
184+
* Row compares are treated as ordinary inequality comparisons on the row's
185+
* first index column whenever possible. We treat their first subkey as if it
186+
* was a simple scalar inequality for the purposes of the logic about required
187+
* keys. This also gives us limited ability to detect contradictory/redundant
188+
* conditions involving a row compare: we can do so whenever it involves an
189+
* SK_ISNULL condition on a row compare's first column (the same rules used
190+
* with simple inequalities work just as well here). We have no ability to
191+
* detect redundant/contradictory conditions in any other row compare case.
192+
* Note in particular that we are unable to merge a row comparison key into a
193+
* skip array (only ordinary inequalities are merged). Any so->keyData[] key
194+
* on a column that comes after a row comparison's first column can therefore
195+
* never be marked as required at present.
187196
*
188197
* Note: the reason we have to copy the preprocessed scan keys into private
189198
* storage is that we are modifying the array based on comparisons of the

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp