Message-ID: <4F8C544F.4080708@cybertec.at>
Date: Mon, 16 Apr 2012 19:18:07 +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: <20120407155042.GB11987@tornado.leadboat.com>
	<20120408142501.GA21513@feivel.credativ.lan>
	<4F81BE55.1010904@cybertec.at>
	<20120408173859.GA4915@feivel.credativ.lan>
	<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>
In-Reply-To: <20120416160448.GA9968@feivel.credativ.lan>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

2012-04-16 18:04 keltez=C3=A9ssel, Michael Meskes =C3=ADrta:
> On Mon, Apr 16, 2012 at 06:24:57AM +0200, Boszormenyi Zoltan wrote:
>> Yes, just like when the readahead window set to 256, FETCH 1024
>> will iterate through 4 windows or FETCH 64 iterates through the
>> same window 4 times. This is the idea behind the "readahead window".
> Really? It's definitely not the idea behind FETCH 1024. Using the same =
window 4
> times for FETCH 64 is the idea though, I agree.

OK. I would like to stretch your agreement a little. :-)

Can we state that caching means that if the cache should serve
the incoming request(s) until the request spills out of it?

If your answer to the above is "yes", then please consider this case:
- readahead window is 256 (via ECPGFETCHSZ)
- FETCH 64 was executed twice, so you are in the middle of the cache
- FETCH 1024 is requested

So, if I understand you correctly, you expect this scenario:
- set a "one-time" readahead window size ( N - # of rows that can be serv=
ed
   =3D 1024 - 128 =3D 768) so the next FETCH by the runtime will fullfill
   this request fully
- serve the request's first 128 rows from the current cache
- for the 129th row, FETCH 768 will be executed
- all subsequent requests use the old readahead size

>> How about allowing the readahead window to be resized for the
>> non-decorated case if the runtime encounters FETCH N and N is
>> greater than the previous window?
> To be resized by what?

By the new FETCH request. Instead of the above, I imagined this:
- the runtime notices that the new request is larger than the current
   readahead window size, modifies the readahead window size upwards,
   so the next FETCH will use it
- serve the request's first 128 rows from the current cache
- for the 129th row, FETCH 1024 will be executed and the remaining
   768 rows will be served from the new cache
- all subsequent requests use the new readahead size, 1024


>   IMO a FETCH N should always be a FETCH N, no matter
> what

This part of your statement contradicts with caching. :-)

> , i.e. if the readahead window is larger, use it, but even if it's smal=
ler
> we should still fetch N at the same time.

So, there can be occasional one-time larger requests but
smaller ones should apply the set window size, right?

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/