Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 69ACB177C3D9; Tue, 17 Apr 2012 00:52:29 -0300 (ADT) Received: from gauss.credativ.com ([93.94.130.89]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SJzSt-0002Ap-P3; Tue, 17 Apr 2012 03:52:29 +0000 Received: from feivel (ip65-44-201-243.z201-44-65.customer.algx.net [65.44.201.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mme@gauss.credativ.com) by gauss.credativ.com (Postfix) with ESMTPSA id 09722550027; Tue, 17 Apr 2012 05:52:13 +0200 (CEST) Received: by feivel (Postfix, from userid 1000) id 9DEC29F21E; Tue, 17 Apr 2012 05:52:08 +0200 (CEST) Date: Tue, 17 Apr 2012 05:52:08 +0200 From: Michael Meskes To: Boszormenyi Zoltan Cc: Noah Misch , Michael Meskes , Robert Haas , PG Hackers , Heikki Linnakangas , Bruce Momjian Subject: Re: ECPG FETCH readahead Message-ID: <20120417035208.GA5465@feivel.credativ.lan> Mail-Followup-To: Boszormenyi Zoltan , Noah Misch , Michael Meskes , Robert Haas , PG Hackers , Heikki Linnakangas , Bruce Momjian References: <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> <4F8C544F.4080708@cybertec.at> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4F8C544F.4080708@cybertec.at> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201204/864 X-Sequence-Number: 206667 On Mon, Apr 16, 2012 at 07:18:07PM +0200, Boszormenyi Zoltan wrote: > OK. I would like to stretch your agreement a little. :-) > ... Yeah, you got a point here. > 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 That means window size goes up to 1024-128 for that one case? > - all subsequent requests use the new readahead size, 1024 Sounds reasonable to me. > So, there can be occasional one-time larger requests but > smaller ones should apply the set window size, right? Yes. I do agree that FETCH N cannot fetch N all the time, but please make= it work like what you suggested to make sure people don't have to recompile. Michael --=20 Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at googlemail dot com VfL Borussia! For=C3=A7a Bar=C3=A7a! Go SF 49ers! Use Debian GNU/Linux, P= ostgreSQL