From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Robert Haas" <robertmhaas(at)gmail(dot)com>, "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, Postgres <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: posix_fadvise v22 |
Date: | 2009-01-12 06:55:56 |
Message-ID: | 87mydxm2rn.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> "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
> submitted.
Hm. the original intent was that effective_io_concurrency 1 meant no
prefetching because there was only one drive.
I wonder if that worked earlier and got lost along the way or if I always had
this wrong.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
From | Date | Subject | |
---|---|---|---|
Next Message | Charlie Savage | 2009-01-12 07:41:57 | Re: 2 small patches that fix 8.3.5 compile issues on Vista+MingW+Msys |
Previous Message | Tom Lane | 2009-01-12 05:19:42 | Re: posix_fadvise v22 |