Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id A7582177C3D9; Tue, 17 Apr 2012 01:03:43 -0300 (ADT) Received: from [87.118.86.135] (helo=km31432.keymachine.de) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SJzdi-00034M-0D; Tue, 17 Apr 2012 04:03:42 +0000 Received: from localhost.localdomain (unknown [87.242.62.156]) by km31432.keymachine.de (Postfix) with ESMTPSA id 08F6A390016A; Tue, 17 Apr 2012 04:10:21 +0000 (UTC) Message-ID: <4F8CEB5A.100@cybertec.at> Date: Tue, 17 Apr 2012 06:02:34 +0200 From: Boszormenyi Zoltan 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 , Michael Meskes , Robert Haas , PG Hackers , Heikki Linnakangas , Bruce Momjian Subject: Re: ECPG FETCH readahead 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> <20120417035208.GA5465@feivel.credativ.lan> In-Reply-To: <20120417035208.GA5465@feivel.credativ.lan> Content-Type: text/plain; charset=UTF-8; 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: 201204/865 X-Sequence-Number: 206668 2012-04-17 05:52 keltez=C3=A9ssel, Michael Meskes =C3=ADrta: > 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? 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) > >> - 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 ma= ke it > work like what you suggested to make sure people don't have to recompil= e. > > Michael --=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/