Re: ECPG FETCH readahead

2012-03-04 17:16 keltezéssel, Michael Meskes írta:
> 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?

The program logic shouldn't change at all. He meant that extra coding effort
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 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,

Something else would be needed. For DML with WHERE CURRENT OF cursor,
the feature should stay disabled even with the environment variable is set
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 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

Best regards,
Zoltán Böszörményi

--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/