Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229])
	by mail.postgresql.org (Postfix) with ESMTP id 1D23ED6F1F2;
	Thu, 29 Mar 2012 09:21:09 -0300 (ADT)
Received: from [87.118.86.135] (helo=km31432.keymachine.de)
	by magus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <zb@cybertec.at>)
	id 1SDELj-0006Ag-M3; Thu, 29 Mar 2012 12:21:08 +0000
Received: from localhost.localdomain (unknown [87.242.59.39])
	by km31432.keymachine.de (Postfix) with ESMTPSA id DAE2E39008CC;
	Thu, 29 Mar 2012 12:25:57 +0000 (UTC)
Message-ID: <4F745394.40007@cybertec.at>
Date: Thu, 29 Mar 2012 14:20:36 +0200
From: Boszormenyi Zoltan <zb@cybertec.at>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120316 Thunderbird/11.0
MIME-Version: 1.0
To: Noah Misch <noah@leadboat.com>
CC: Robert Haas <robertmhaas@gmail.com>,
	Michael Meskes <meskes@postgresql.org>,
	PG Hackers <pgsql-hackers@postgresql.org>,
	Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
	Bruce Momjian <bruce@momjian.us>
Subject: Re: ECPG FETCH readahead
References: <4CB6D3C8.3020709@cybertec.at> <4EC41434.7010603@cybertec.at>
	<4EFC36EF.1060308@cybertec.at>
	<20120302164105.GD23100@tornado.leadboat.com>
	<4F538B4C.1030605@cybertec.at>
	<20120305185632.GE13348@tornado.leadboat.com>
	<4F55A9AD.6050600@cybertec.at>
	<20120306110658.GC15988@tornado.leadboat.com>
	<CA+TgmoaBGLpW5V3nFES-McLbZyY_9nUvpnFLjT7zAYuVPu809A@mail.gmail.com>
	<4F6D9893.3030300@cybertec.at>
	<20120329004323.GA17329@tornado.leadboat.com>
	<4F74409C.3050904@cybertec.at>
In-Reply-To: <4F74409C.3050904@cybertec.at>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Host-Lookup-Failed: Reverse DNS lookup failed for 87.118.86.135 (deferred)
X-Pg-Spam-Score: -1.1 (-)
X-Archive-Number: 201203/1775
X-Sequence-Number: 205656

2012-03-29 12:59 keltez=E9ssel, Boszormenyi Zoltan =EDrta:
> 2012-03-29 02:43 keltez=E9ssel, Noah Misch =EDrta:
>> On Sat, Mar 24, 2012 at 10:49:07AM +0100, Boszormenyi Zoltan wrote:
>>> +    the window size may be modified by setting the<literal>ECPGFETCH=
SZ</literal>
>>> +    environment variable to a different value.
>> I had in mind that DECLARE statements adorned with READAHEAD syntax wo=
uld
>> always behave precisely as written, independent of ECPGFETCHSZ or "ecp=
g -R".
>> Unadorned DECLARE statements would use ECPGFETCHSZ if set, then the va=
lue
>> passed to "ecpg -R" if provided, and finally a value of 1 (no readahea=
d) in
>> the absence of both ECPGFETCHSZ and "ecpg -R".  Did you do it differen=
tly for
>> a particular reason?  I don't particularly object to what you've imple=
mented,
>> but I'd be curious to hear your thinking.
>
> What I had in mind was:
>
> NO READAHEAD =3D=3D READAHEAD 0. This will translate into 1 tuple sized
> readahead window that cannot be modified by ECPGFETCHSZ.

After the core patch, this is not totally true yet. The "NO READAHEAD"
cursors don't go through the new cursor functions at all. But cursor.c
is prepared for the second patch that makes all cursors use the caching c=
ode.

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi

--=20
----------------------------------
Zolt=E1n B=F6sz=F6rm=E9nyi
Cybertec Sch=F6nig&  Sch=F6nig GmbH
Gr=F6hrm=FChlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
      http://www.postgresql.at/