Robert Haas <robertmh...@gmail.com> writes: > On Fri, Mar 13, 2009 at 10:06 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> I assume you meant effective_io_concurrency. We'd still need a special >> case because the default is currently hard-wired at 1, not 0, if >> configure thinks the function exists. Also there's a posix_fadvise call >> in xlog.c that that parameter doesn't control anyhow. > > I think 1 should mean no prefetching, rather than 0. If the number of > concurrent I/O requests was 0, that would mean you couldn't perform > any I/O at all.
That is actually how I had intended it but apparently I messed it up at some point such that later patches were doing some prefetching at 1 and there was no way to disable it. When Tom reviewed it he corrected the inability to disable prefetching by making 0 disable prefetching. I didn't think it was worth raising as an issue but I didn't realize we were currently doing prefetching by default? i didn't realize that. Even on a system with posix_fadvise there's nothing much to be gained unless the data is on a RAID device, so the original objection holds anyways. We shouldn't do any prefetching unless the user tells us to. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
