Re: ECPG FETCH readahead
От | Noah Misch |
---|---|
Тема | Re: ECPG FETCH readahead |
Дата | |
Msg-id | 20120305185004.GD13348@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: ECPG FETCH readahead (Michael Meskes <meskes@postgresql.org>) |
Список | pgsql-hackers |
On Sun, Mar 04, 2012 at 05:16:06PM +0100, Michael Meskes wrote: > On Fri, Mar 02, 2012 at 11:41:05AM -0500, Noah Misch wrote: > > 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. On further reflection, I agree with you here. The prospect for queries that call volatile functions changed my mind; they would exhibit different functional behavior under readahead. We mustn't silently give affected programs different semantics. Thanks, nm
В списке pgsql-hackers по дате отправления: