Re: Index Skip Scan - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: Index Skip Scan
Date
Msg-id 20200515123802.xhppukhcqemmnbqe@localhost
Whole thread Raw
In response to Re: Index Skip Scan  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: Index Skip Scan  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-hackers
> On Wed, May 13, 2020 at 02:37:21PM +0530, Dilip Kumar wrote:
>
> + if (_bt_scankey_within_page(scan, so->skipScanKey, so->currPos.buf, dir))
> + {
>
> Here we expect whether the "next" unique key can be found on this page
> or not, but we are using the function which suggested whether the
> "current" key can be found on this page or not.  I think in boundary
> cases where the high key is equal to the current key, this function
> will return true (which is expected from this function), and based on
> that we will simply scan the current page and IMHO that cost could be
> avoided no?

Yes, looks like you're right, there is indeed an unecessary extra scan
happening. To avoid that we can see the key->nextkey and adjust higher
boundary correspondingly. Will also add this into the next rebased
patch, thanks!



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: PG 13 release notes, first draft
Next
From: Fujii Masao
Date:
Subject: Re: PG 13 release notes, first draft