From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Dmitry Dolgov <9erthalion6(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Floris Van Nee <florisvannee(at)optiver(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Subject: | Re: Index Skip Scan (new UniqueKeys) |
Date: | 2020-07-08 22:44:26 |
Message-ID: | CAH2-WznUY=0_yYek3ciNv4-ObotrWokAZbGnWjEsqxZ4oMWCGg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 9, 2020 at 3:20 AM Dmitry Dolgov <9erthalion6(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2020-07-08 23:07:57 | Re: min_safe_lsn column in pg_replication_slots view |
Previous Message | David Rowley | 2020-07-08 22:25:14 | Re: Hybrid Hash/Nested Loop joins and caching results from subplans |