Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 4D0F98D31F0; Sun, 4 Mar 2012 12:15:43 -0400 (AST) Received: from gauss.credativ.com ([93.94.130.89]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1S4E62-0003b0-A1; Sun, 04 Mar 2012 16:15:43 +0000 Received: from feivel (p5DC92B5D.dip.t-dialin.net [93.201.43.93]) (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 5FD2455013C; Sun, 4 Mar 2012 17:15:26 +0100 (CET) Received: by feivel (Postfix, from userid 1000) id 5BF2D9F128; Sun, 4 Mar 2012 17:16:06 +0100 (CET) Date: Sun, 4 Mar 2012 17:16:06 +0100 From: Michael Meskes To: Noah Misch Cc: Boszormenyi Zoltan , Michael Meskes , PG Hackers , Robert Haas , Heikki Linnakangas , Bruce Momjian Subject: Re: ECPG FETCH readahead Message-ID: <20120304161606.GA4706@feivel.credativ.lan> Mail-Followup-To: Noah Misch , Boszormenyi Zoltan , Michael Meskes , PG Hackers , Robert Haas , Heikki Linnakangas , Bruce Momjian References: <201006232042.o5NKgb503695@momjian.us> <4C2308FD.1090300@cybertec.at> <4C231F9E.6000102@enterprisedb.com> <20100624121922.GD24137@feivel.credativ.lan> <4CB6D3C8.3020709@cybertec.at> <4EC41434.7010603@cybertec.at> <4EFC36EF.1060308@cybertec.at> <20120302164105.GD23100@tornado.leadboat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20120302164105.GD23100@tornado.leadboat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201203/156 X-Sequence-Number: 204038 On Fri, Mar 02, 2012 at 11:41:05AM -0500, Noah Misch wrote: > We yet lack a consensus on whether native ECPG apps should have access = to the > feature. My 2c is to make it available, because it's useful syntactic = sugar. > If your program independently processes each row of an arbitrary-length= result > set, current facilities force you to add an extra outer loop to batch t= he > FETCHes for every such code site. Applications could define macros to > abstract that pattern, but this seems common-enough to justify bespoke > handling. Besides, minimalists already use libpq directly. Sorry, I don't really understand what you're saying here. The program log= ic won't change at all when using this feature or what do I misunderstand? > I suggest enabling the feature by default but drastically reducing the = default > readahead chunk size from 256 to, say, 5. That still reduces the FETCH= round > trip overhead by 80%, but it's small enough not to attract pathological > behavior on a workload where each row is a 10 MiB document. I would no= t offer > an ecpg-time option to disable the feature per se. Instead, let the us= er set > the default chunk size at ecpg time. A setting of 1 effectively disabl= es the > feature, though one could later re-enable it with ECPGFETCHSZ. Using 1 to effectively disable the feature is fine with me, but I strongl= y object any default enabling this feature. It's farily easy to create case= s with pathological behaviour and this features is not standard by any means. I = figure a normal programmer would expect only one row being transfered when fetch= ing one. Other than that, thanks for the great review. 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