Re: posix_fadvise v22 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: posix_fadvise v22
Date
Msg-id 2083.1231706462@sss.pgh.pa.us
Whole thread Raw
In response to Re: posix_fadvise v22  ("Robert Haas" <robertmhaas@gmail.com>)
List pgsql-hackers
"Robert Haas" <robertmhaas@gmail.com> writes:
> 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.

Probably not; I'm busy hacking on the code anyway, fixing minor issues
like its failure to do anything sane with temp tables.

A question about that part of the code: I see that PrefetchBuffer simply
does nothing if it finds the target page already in a buffer.  I wonder
whether that's sufficient, or whether we ought to do something to try
to ensure that the buffer doesn't get evicted in the near future (ie,
before we actually get to use it).

Simply advancing the usage_count seems too strong because when you
add in the upcoming ReadBuffer, we'd be advancing usage_count twice
for a single use of the page whenever it happened to get prefetched.
We could alleviate that by only advancing usage_count if it's 0, but
that seems like a band-aid not a real fix.

I also thought about setting a buffer flag bit showing that prefetch has
occurred, but then you have to worry about when/how to clear it if the
actual read never occurs.

Thoughts?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: posix_fadvise v22
Next
From: Jeff Davis
Date:
Subject: Re: Review: B-Tree emulation for GIN