From: Michael Meskes <meskes@postgresql.org>
To: Noah Misch <noah@leadboat.com>
Cc: Boszormenyi Zoltan <zb@cybertec.at>
Cc: Michael Meskes <meskes@postgresql.org>
Cc: PG Hackers <pgsql-hackers@postgresql.org>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Bruce Momjian <bruce@momjian.us>
Subject: Re: ECPG FETCH readahead
Date: Sun, 4 Mar 2012 17:16:06 +0100
Message-ID: <20120304161606.GA4706@feivel.credativ.lan> (raw)
In-Reply-To: <20120302164105.GD23100@tornado.leadboat.com>
References: <201006232042.o5NKgb503695@momjian.us>
<4C2308FD.1090300@cybertec.at>
<4C231F9E.6000102@enterprisedb.com>
<20100624121922.GD24137@feivel.credativ.lan>
<AANLkTinij9ULnS54zKsdAJnhvuj-07-8-T-D=Nwk6f14@mail.gmail.com>
<4CB6D3C8.3020709@cybertec.at>
<4EC41434.7010603@cybertec.at>
<4EFC36EF.1060308@cybertec.at>
<20120302164105.GD23100@tornado.leadboat.com>
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 the
> 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 logic
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 not offer
> an ecpg-time option to disable the feature per se. Instead, let the user set
> the default chunk size at ecpg time. A setting of 1 effectively disables the
> feature, though one could later re-enable it with ECPGFETCHSZ.
Using 1 to effectively disable the feature is fine with me, but I strongly
object any default enabling this feature. It's farily easy to create cases 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 fetching
one.
Other than that, thanks for the great review.
Michael
--
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ça Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: meskes@postgresql.org, noah@leadboat.com, zb@cybertec.at, robertmhaas@gmail.com, heikki.linnakangas@enterprisedb.com, bruce@momjian.us
Subject: Re: ECPG FETCH readahead
In-Reply-To: <20120304161606.GA4706@feivel.credativ.lan>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox