Message-ID: <4F95613B.2030904@cybertec.at>
Date: Mon, 23 Apr 2012 16:03:39 +0200
From: Boszormenyi Zoltan <zb@cybertec.at>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: Noah Misch <noah@leadboat.com>, Michael Meskes <meskes@postgresql.org>,
	Robert Haas <robertmhaas@gmail.com>,
	PG Hackers <pgsql-hackers@postgresql.org>,
	Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
	Bruce Momjian <bruce@momjian.us>
Subject: Re: ECPG FETCH readahead
References: <4F83E2B9.3030302@cybertec.at>
	<20120410143722.GC6129@tornado.leadboat.com>
	<20120410145501.GA11554@feivel.credativ.lan>
	<4F847453.9060200@cybertec.at>
	<20120416024636.GA4536@feivel.credativ.lan>
	<4F8B9F19.3040403@cybertec.at>
	<20120416160448.GA9968@feivel.credativ.lan>
	<4F8C544F.4080708@cybertec.at>
	<20120417035208.GA5465@feivel.credativ.lan>
	<4F8CEB5A.100@cybertec.at>
	<20120417044819.GA9043@feivel.credativ.lan>
In-Reply-To: <20120417044819.GA9043@feivel.credativ.lan>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,

2012-04-17 06:48 keltez=C3=A9ssel, Michael Meskes =C3=ADrta:
> On Tue, Apr 17, 2012 at 06:02:34AM +0200, Boszormenyi Zoltan wrote:
>> I listed two scenarios.
>> 1. occasional bump of the readahead window for large requests,
>>     for smaller requests it uses the originally set size
>> 2. permanent bump of the readahead window for large requests
>>     (larger than previously seen), all subsequent requests use
>>     the new size
>>
>> Both can be implemented easily, which one do you prefer?
>> If you always use very large requests, 1) behaves like 2)
> I'd say let's go for #2. #1 is probably more efficient but not what the
> programmer asked us to do. After all it's easy to increase the window s=
ize
> accordingly if you want so as a programmer.
>
> Michael

OK, I will implement #2. Another question popped up: what to do
with FETCH ALL? The current readahead window size or temporarily
bumping it to say some tens of thousands can be used. We may not
know how much is the "all records". This, although lowers performance,
saves memory.

Please, don't apply this patch yet. I discovered a rather big hole
that can confuse the cursor position tracking if you do this:

DECLARE mycur;
MOVE ABSOLUTE n IN mycur;
MOVE BACKWARD m IN mycur;

If (n+m) is greater, but (n-m) is smaller than the number
of rows in the cursor, the backend's and the caching code's
ideas about where the cursor is will differ. I need to fix this
before it can be applied.

That will also need a new round of review. Sorry for that.

Best regards,
Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi

--=20
----------------------------------
Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi
Cybertec Sch=C3=B6nig&  Sch=C3=B6nig GmbH
Gr=C3=B6hrm=C3=BChlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
      http://www.postgresql.at/