pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Dmitry Dolgov <9erthalion6@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Floris Van Nee <florisvannee@optiver.com>
Cc: David Rowley <dgrowleyml@gmail.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: Jesper Pedersen <jesper.pedersen@redhat.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Thomas Munro <thomas.munro@gmail.com>
Cc: James Coleman <jtc331@gmail.com>
Cc: Rafia Sabih <rafia.pghackers@gmail.com>
Cc: Jeff Janes <jeff.janes@gmail.com>
Cc: bhushan.uparkar@gmail.com <bhushan.uparkar@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Cc: Alexander Korotkov <a.korotkov@postgrespro.ru>
Subject: Re: Index Skip Scan
Date: Fri, 15 May 2020 14:38:02 +0200
Message-ID: <20200515123802.xhppukhcqemmnbqe@localhost> (raw)
In-Reply-To: <CAFiTN-u-=aMJLQJg=kdiKoQkKtiLBpOHH=0gtJ2FhqPZgx_6Rg@mail.gmail.com>
References: <80ef5f0744f542b18e508fb589a6425a@opammb0562.comp.optiver.com>
	<CAFiTN-tp8S3BTwYXT33tnY=53fNCsS4ZZUjbEFtcJym1acoLeA@mail.gmail.com>
	<20200406163941.rh3okji2rhbnptyt@localhost>
	<8abe43ac82714c2f9044fb8bac0ebfd0@opammb0562.comp.optiver.com>
	<20200407194220.edf4nbi7l4cpxk4v@localhost>
	<CAFiTN-sRRGZ_6za6qhN+e98wCfcLrn4bE35RqxycteKbDutorA@mail.gmail.com>
	<20200510174935.teqyazdw6jj6vh47@localhost>
	<CAFiTN-t1dR7zq=PN8HiiouE3MfBrLrVfq3NXa37=dWsf_MtgAw@mail.gmail.com>
	<20200511112655.ijz2sjltzdpif3cn@localhost>
	<CAFiTN-u-=aMJLQJg=kdiKoQkKtiLBpOHH=0gtJ2FhqPZgx_6Rg@mail.gmail.com>

> 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!





view thread (248+ messages)  latest in thread

Message-ID: <20200515123802.xhppukhcqemmnbqe@localhost>
Permalink:  ../20200515123802.xhppukhcqemmnbqe@localhost/
Also on:    postgresql.org/message-id/20200515123802.xhppukhcqemmnbqe@localhost

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: 9erthalion6@gmail.com, dilipbalaut@gmail.com, florisvannee@optiver.com, dgrowleyml@gmail.com, horikyota.ntt@gmail.com, tomas.vondra@2ndquadrant.com, pg@bowt.ie, jesper.pedersen@redhat.com, alvherre@2ndquadrant.com, thomas.munro@gmail.com, jtc331@gmail.com, rafia.pghackers@gmail.com, jeff.janes@gmail.com, bhushan.uparkar@gmail.com, a.korotkov@postgrespro.ru
  Subject: Re: Index Skip Scan
  In-Reply-To: <20200515123802.xhppukhcqemmnbqe@localhost>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox