"Robert Haas" <robertmhaas(at)gmail(dot)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
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
In response to
pgsql-hackers by date
|Next:||From: Gregory Stark||Date: 2009-01-12 06:55:56|
|Subject: Re: posix_fadvise v22|
|Previous:||From: Tom Lane||Date: 2009-01-12 05:10:45|
|Subject: pgsql: Implement prefetching via posix_fadvise() for bitmap index scans.|