Re: [GENERAL] effective_io_concurrency increasing - Mailing list pgsql-general

From Peter Geoghegan
Subject Re: [GENERAL] effective_io_concurrency increasing
Date
Msg-id CAH2-Wzmv371Eib7Z7HnKb9PGUriVfWS=0h6qjtxKgCpHbLBp8A@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] effective_io_concurrency increasing  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: [GENERAL] effective_io_concurrency increasing  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: [GENERAL] effective_io_concurrency increasing  (Andres Freund <andres@anarazel.de>)
List pgsql-general
On Mon, Jun 19, 2017 at 8:36 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> Unfortunately, it is only implemented in very narrow circumstances.  You
> have to be doing bitmap index scans of many widely scattered rows to make it
> useful.  I don't think that this is all that common of a situation.  The
> problem is that at every point in the scan, it has to be possible to know
> what data block it is going to want N iterations in the future, so you can
> inform the kernel to pre-fetch it.  That is only easy to know for bitmap
> scans.

I think that you could prefetch in index scans by using the
pointers/downlinks in the immediate parent page of the leaf page that
the index scan currently pins. The sibling pointer in the leaf itself
is no good for this, because there is only one block to prefetch
available at a time.

I think that this is the way index scan prefetch is normally
implemented. Index scans will on average have a much more random
access pattern than what is typical for bitmap heap scans, making this
optimization more compelling, so hopefully someone will get around to
this.

--
Peter Geoghegan


pgsql-general by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: [GENERAL] performance considerations of jsonb vs separate rows
Next
From: Alvaro Herrera
Date:
Subject: Re: [GENERAL] effective_io_concurrency increasing