Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 4E6452BE258; Sun, 15 Apr 2012 23:46:56 -0300 (ADT) Received: from gauss.credativ.com ([93.94.130.89]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SJbxt-0004qj-Bn; Mon, 16 Apr 2012 02:46:55 +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 D2EFB55010A; Mon, 16 Apr 2012 04:46:38 +0200 (CEST) Received: by feivel (Postfix, from userid 1000) id 5E8749F21E; Mon, 16 Apr 2012 04:46:36 +0200 (CEST) Date: Mon, 16 Apr 2012 04:46:36 +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: <20120416024636.GA4536@feivel.credativ.lan> Mail-Followup-To: Boszormenyi Zoltan , Noah Misch , Michael Meskes , Robert Haas , PG Hackers , Heikki Linnakangas , Bruce Momjian References: <4F74E6A7.8040204@cybertec.at> <20120407112008.GA2286@feivel.credativ.lan> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4F847453.9060200@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/793 X-Sequence-Number: 206596 On Tue, Apr 10, 2012 at 07:56:35PM +0200, Boszormenyi Zoltan wrote: > With the above, it would be possible to use a comma separated list of "= -r" > suboptions, e.g. "-r prepare,questionmarks,readahead=3D16" in one optio= n. Yes, that sounds like a good plan. But of course it's outside the scope o= f this patch, so we can add this later on. > - Also added a note to the documentation about a possible performance t= rap > if a previously written ECPG application uses its own custom readahea= d via > multi-row FETCH statements. I didn't know that before you send this patch. Noah, did you? Frankly, I don't like this at all. If I got it right that means a FETCH N= is essantially computed as N times FETCH 1 unless you either add a non-stand= ard option to the DECLARE statement or you add a command-line option to ecpg.= Did I get that right? If so we would deliberately make ecpglib work incorrectly and remove performance. Why is that? I'm interested in what others think, but to me = that sounds like a show-stopper. 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