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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
