Re: posix_fadvise v22 - Mailing list pgsql-hackers

From Robert Haas
Subject Re: posix_fadvise v22
Date
Msg-id 603c8f070901111145n720e0abdwb95720d1651d63b0@mail.gmail.com
Whole thread Raw
In response to Re: posix_fadvise v22  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: posix_fadvise v22  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> * As coded, it generates prefetch bursts that are much too large and too
> widely spaced to be effective, not to mention that they entirely
> ignore the effective_io_concurrency control knob as well as the order
> in which the pages will actually be needed.  I wonder now whether
> Robert's inability to see any benefit came because he was testing
> indexscans and not bitmap scans.

Nope, bitmap index scans.  For some reason I was having trouble
generating a plan that included an index scan, so I took the easy way
out and tested what was in front of me.  :-)

> What I intend to do over the next day or so is commit the prefetch
> infrastructure and the bitmap scan prefetch logic, but I'm bouncing the
> indexscan part back for rework.  I think that it should be implemented
> in or near index_getnext() and pay attention to
> effective_io_concurrency.

FWIW, following your first set of commits, I extracted, cleaned up,
and re-posted the uncommitted portion of the patch last night.  Based
on this it doesn't sound like there's much point in continuing to do
that, but I'm happy to do so if anyone thinks otherwise.

...Robert


pgsql-hackers by date:

Previous
From: Devrim GÜNDÜZ
Date:
Subject: Re: foreign_data test fails with non-C locale
Next
From: Devrim GÜNDÜZ
Date:
Subject: Re: foreign_data test fails with non-C locale