Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 93675145EA43; Tue, 24 Apr 2012 05:17:32 -0300 (ADT) Received: from gauss.credativ.com ([93.94.130.89]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SMawD-0000xP-C3; Tue, 24 Apr 2012 08:17:31 +0000 Received: from feivel (exit.credativ.com [87.139.82.80]) (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 8DC7D550123; Tue, 24 Apr 2012 10:17:14 +0200 (CEST) Received: by feivel (Postfix, from userid 1000) id 33C1B9F554; Tue, 24 Apr 2012 10:17:14 +0200 (CEST) Date: Tue, 24 Apr 2012 10:17:14 +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: <20120424081714.GA12034@feivel.credativ.lan> Mail-Followup-To: Boszormenyi Zoltan , Noah Misch , Michael Meskes , Robert Haas , PG Hackers , Heikki Linnakangas , Bruce Momjian References: <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> <4F95613B.2030904@cybertec.at> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4F95613B.2030904@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/1115 X-Sequence-Number: 206918 > 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. I would say doing a large fetch in two or three batches won't cost too mu= ch in terms of performance. > Please, don't apply this patch yet. I discovered a rather big hole > that can confuse the cursor position tracking if you do this: > ... > That will also need a new round of review. Sorry for that. No problem, better to find it now instead of after release.=20 Anyway, I moved the patch to 2012-next (I hope I did it correctly) so 201= 2-1 can be closed. Let's try to get this patch done in the next commit fest. 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