Message-ID: <4F5399AA.5020104@cybertec.at>
Date: Sun, 04 Mar 2012 17:34:50 +0100
From: Boszormenyi Zoltan <zb@cybertec.at>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
MIME-Version: 1.0
To: Noah Misch <noah@leadboat.com>, Michael Meskes <meskes@postgresql.org>,
	PG Hackers <pgsql-hackers@postgresql.org>,
	Robert Haas <robertmhaas@gmail.com>,
	Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
	Bruce Momjian <bruce@momjian.us>
Subject: Re: ECPG FETCH readahead
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>
	<20120304161606.GA4706@feivel.credativ.lan>
In-Reply-To: <20120304161606.GA4706@feivel.credativ.lan>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2012-03-04 17:16 keltez=C3=A9ssel, Michael Meskes =C3=ADrta:
> 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-lengt=
h 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 l=
ogic
> won't change at all when using this feature or what do I misunderstand?

The program logic shouldn't change at all. He meant that extra coding eff=
ort
is needed if you want manual caching. It requires 2 loops instead of 1 if=
 you use
FETCH N (N>1).

>
>> I suggest enabling the feature by default but drastically reducing the=
 default
>> readahead chunk size from 256 to, say, 5.  That still reduces the FETC=
H round
>> trip overhead by 80%, but it's small enough not to attract pathologica=
l
>> behavior on a workload where each row is a 10 MiB document.  I would n=
ot offer
>> an ecpg-time option to disable the feature per se.  Instead, let the u=
ser set
>> the default chunk size at ecpg time.  A setting of 1 effectively disab=
les the
>> feature, though one could later re-enable it with ECPGFETCHSZ.
> Using 1 to effectively disable the feature is fine with me,

Something else would be needed. For DML with  WHERE CURRENT OF cursor,
the feature should stay disabled even with the environment variable is se=
t
without adding any decoration to the DECLARE statement. The safe thing
would be to distinguish between uncached (but cachable) and uncachable
cases. A single value cannot work.

>  but I strongly
> object any default enabling this feature. It's farily easy to create ca=
ses 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 fet=
ching
> one.
>
> Other than that, thanks for the great review.
>
> Michael

Best regards,
Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi

--=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/