Received: from localhost (unknown [200.46.204.183])
	by mail.postgresql.org (Postfix) with ESMTP id C3833632327
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Mon, 12 Jan 2009 09:03:11 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 95668-02-2
	for <pgsql-hackers-postgresql.org@mail.postgresql.org>;
	Mon, 12 Jan 2009 09:03:02 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id F07AC632321
	for <pgsql-hackers@postgresql.org>;
	Mon, 12 Jan 2009 09:03:02 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id n0CD2OMr027520;
	Mon, 12 Jan 2009 08:02:24 -0500 (EST)
To: Gregory Stark <stark@enterprisedb.com>
cc: "Robert Haas" <robertmhaas@gmail.com>,
	"ITAGAKI Takahiro" <itagaki.takahiro@oss.ntt.co.jp>,
	Postgres <pgsql-hackers@postgresql.org>
Subject: Re: posix_fadvise v22 
In-reply-to: <87mydxm2rn.fsf@oxford.xeocode.com> 
References: <FDDBA24E-FF4D-4654-BA75-692B3BA71B97@enterprisedb.com>
	<8347.1229012970@sss.pgh.pa.us>
	<4136ffa0812110911x4914a951o6ca502879e3dede7@mail.gmail.com>
	<87k5a6tmy7.fsf@oxford.xeocode.com>
	<603c8f070901011230t1afa6644racb715b975078054@mail.gmail.com>
	<10658.1230843315@sss.pgh.pa.us>
	<603c8f070901011843p121e40afu35c4a7bdc51c051c@mail.gmail.com>
	<13517.1231737582@sss.pgh.pa.us>
	<87mydxm2rn.fsf@oxford.xeocode.com>
Comments: In-reply-to Gregory Stark <stark@enterprisedb.com>
	message dated "Mon, 12 Jan 2009 01:55:56 -0500"
Date: Mon, 12 Jan 2009 08:02:24 -0500
Message-ID: <27519.1231765344@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none
X-Spam-Level: 
X-Archive-Number: 200901/836
X-Sequence-Number: 131480

Gregory Stark <stark@enterprisedb.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> 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.

Well, "no prefetch" is an entirely different behavior from "prefetch one
block ahead".  Given the way you've defined the GUC, a setting of one
has to mean the latter.  My complaint was basically that with the patch
applied, the code was physically incapable of providing the former.
Which you'd surely want if only for testing/comparison purposes.

			regards, tom lane