Re: Index Skip Scan - Mailing list pgsql-hackers
From | Dmitry Dolgov |
---|---|
Subject | Re: Index Skip Scan |
Date | |
Msg-id | 20200510174935.teqyazdw6jj6vh47@localhost Whole thread Raw |
In response to | Re: Index Skip Scan (Dilip Kumar <dilipbalaut@gmail.com>) |
Responses |
Re: Index Skip Scan
|
List | pgsql-hackers |
> On Sat, Apr 11, 2020 at 03:17:25PM +0530, Dilip Kumar wrote: > > Some more comments... Thanks for reviewing. Since this patch took much longer than I expected, it's useful to have someone to look at it with a "fresh eyes". > + so->skipScanKey->nextkey = ScanDirectionIsForward(dir); > + _bt_update_skip_scankeys(scan, indexRel); > + > ....... > + /* > + * We haven't found scan key within the current page, so let's scan from > + * the root. Use _bt_search and _bt_binsrch to get the buffer and offset > + * number > + */ > + so->skipScanKey->nextkey = ScanDirectionIsForward(dir); > + stack = _bt_search(scan->indexRelation, so->skipScanKey, > + &buf, BT_READ, scan->xs_snapshot); > > Why do we need to set so->skipScanKey->nextkey = > ScanDirectionIsForward(dir); multiple times? I think it is fine to > just set it once? I believe it was necessary for previous implementations, but in the current version we can avoid this, you're right. > +static inline bool > +_bt_scankey_within_page(IndexScanDesc scan, BTScanInsert key, > + Buffer buf, ScanDirection dir) > +{ > + OffsetNumber low, high; > + Page page = BufferGetPage(buf); > + BTPageOpaque opaque = (BTPageOpaque) PageGetSpecialPointer(page); > + > + low = P_FIRSTDATAKEY(opaque); > + high = PageGetMaxOffsetNumber(page); > + > + if (unlikely(high < low)) > + return false; > + > + return (_bt_compare(scan->indexRelation, key, page, low) > 0 && > + _bt_compare(scan->indexRelation, key, page, high) < 1); > +} > > I think the high key condition should be changed to > _bt_compare(scan->indexRelation, key, page, high) < 0 ? Because if > prefix qual is equal to the high key then also there is no point in > searching on the current page so we can directly skip. From nbtree/README and comments to functions like _bt_split I've got an impression that the high key could be equal to the last item on the leaf page, so there is a point in searching. Is that incorrect? > + /* Check if an index skip scan is possible. */ > + can_skip = enable_indexskipscan & index->amcanskip; > + > + /* > + * Skip scan is not supported when there are qual conditions, which are not > + * covered by index. The reason for that is that those conditions are > + * evaluated later, already after skipping was applied. > + * > + * TODO: This implementation is too restrictive, and doesn't allow e.g. > + * index expressions. For that we need to examine index_clauses too. > + */ > + if (root->parse->jointree != NULL) > + { > + ListCell *lc; > + > + foreach(lc, (List *)root->parse->jointree->quals) > + { > + Node *expr, *qual = (Node *) lfirst(lc); > + Var *var; > > I think we can avoid checking for expression if can_skip is already false. Yes, that makes sense. I'll include your suggestions into the next rebased version I'm preparing.
pgsql-hackers by date: