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

From Alvaro Herrera
Subject Re: [GENERAL] effective_io_concurrency increasing
Date
Msg-id 20170619222521.usjnkzgabzi2ocvx@alvherre.pgsql
Whole thread Raw
In response to Re: [GENERAL] effective_io_concurrency increasing  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: [GENERAL] effective_io_concurrency increasing  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-general
Peter Geoghegan wrote:
> 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.

Surely you could prefetch all the heap pages pointed to by index items
in the current leaf index page ...

--
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-general by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [GENERAL] effective_io_concurrency increasing
Next
From: Peter Geoghegan
Date:
Subject: Re: [GENERAL] effective_io_concurrency increasing