On Tue, Jun 9, 2020 at 3:20 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> * Btree-implementation contains btree specific code to implement amskip,
> introduced in the previous patch.
The way that you're dealing with B-Tree tuples here needs to account
for posting list tuples:
> + currItem = &so->currPos.items[so->currPos.lastItem];
> + itup = (IndexTuple) (so->currTuples + currItem->tupleOffset);
> + nextOffset = ItemPointerGetOffsetNumber(&itup->t_tid);
But I wonder more generally what the idea here is. The following
comments that immediately follow provide some hints:
> + /*
> + * To check if we returned the same tuple, try to find a
> + * startItup on the current page. For that we need to update
> + * scankey to match the whole tuple and set nextkey to return
> + * an exact tuple, not the next one. If the nextOffset is the
> + * same as before, it means we are in the loop, return offnum
> + * to the original position and jump further
> + */
Why does it make sense to use the offset number like this? It isn't
stable or reliable. The patch goes on to do this:
> + startOffset = _bt_binsrch(scan->indexRelation,
> + so->skipScanKey,
> + so->currPos.buf);
> +
> + page = BufferGetPage(so->currPos.buf);
> + maxoff = PageGetMaxOffsetNumber(page);
> +
> + if (nextOffset <= startOffset)
> + {
Why compare a heap TID's offset number (an offset number for a heap
page) to another offset number for a B-Tree leaf page? They're
fundamentally different things.
--
Peter Geoghegan
