On 06/16/2018 12:06 PM, Thomas Munro wrote:
On Sat, Jun 16, 2018 at 9:38 PM, Tomas Vondra
<tomas.von...@2ndquadrant.com> wrote:
On 06/15/2018 08:01 PM, Andres Freund wrote:
On 2018-06-14 10:13:44 +0300, Konstantin Knizhnik wrote:
On 14.06.2018 09:52, Thomas Munro wrote:
Why stop at the page cache... what about shared buffers?
It is good question. I thought a lot about prefetching directly to shared
buffers.
I think that's definitely how this should work. I'm pretty strongly
opposed to a prefetching implementation that doesn't read into s_b.
Could you elaborate why prefetching into s_b is so much better (I'm sure it has
advantages, but I suppose prefetching into page cache would be much easier to
implement).
posix_fadvise(POSIX_FADV_WILLNEED) might already get most of the
speed-up available here in the short term for this immediate
application, but in the long term a shared buffers prefetch system is
one of the components we'll need to support direct IO.
Sure. Assuming the switch to direct I/O will happen (it probably will,
sooner or later), my question is whether this patch should be required
to introduce the prefetching into s_b. Or should we use posix_fadvise
for now, get most of the benefit, and leave the prefetch into s_b as an
improvement for later?
The thing is - we're already doing posix_fadvise prefetching in bitmap
heap scans, it would not be putting additional burden on the direct I/O
patch (hypothetical, so far).
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
