Re: posix_fadvise v22 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: posix_fadvise v22
Date
Msg-id 13517.1231737582@sss.pgh.pa.us
Whole thread Raw
In response to Re: posix_fadvise v22  ("Robert Haas" <robertmhaas@gmail.com>)
Responses Re: posix_fadvise v22  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
"Robert Haas" <robertmhaas@gmail.com> writes:
> OK, here's an update of Greg's patch with the runtime configure test
> ripped out, some minor documentation tweaks, and a few unnecessary
> whitespace diff hunks quashed.  I think this is about ready for
> committer review.

I've applied most of this, with a couple of notable revisions:

1. The runtime check on whether posix_fadvise works is really gone.
We'll see whether we need to put anything back, but I think our first
try should be under the assumption that it works.  (BTW, I was wrong
in my earlier claim that the buildfarm wouldn't exercise posix_fadvise
by default --- the patch defaults to io_concurrency = 1 if fadvise
is available, so it will try to prefetch one page ahead.)

2. I fixed it so that setting effective_io_concurrency to zero disables
prefetching altogether; there was no way to do that in the patch as
submitted.

3. I did not apply the changes in nbtsearch.c, since as I mentioned
earlier I wasn't convinced it's a reasonable approach.  We can argue
about that some more, but even if 8.4 ships with concurrency only
for bitmap scans, it's still useful.

The two main loose ends that could stand further work are the
plain-index-scan case and the question of whether PrefetchBuffer
should try to protect an already-existing buffer from being evicted.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Robert Haas"
Date:
Subject: Re: Documenting pglesslog
Next
From: Gregory Stark
Date:
Subject: Re: posix_fadvise v22