From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Michael Meskes <meskes(at)postgresql(dot)org> |
Cc: | Boszormenyi Zoltan <zb(at)cybertec(dot)at>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us> |
Subject: | Re: ECPG FETCH readahead |
Date: | 2012-03-05 18:50:04 |
Message-ID: | 20120305185004.GD13348@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2012-03-05 18:56:32 | Re: ECPG FETCH readahead |
Previous Message | Alvaro Herrera | 2012-03-05 18:37:53 | Re: foreign key locks, 2nd attempt |