From: | Böszörményi Zoltán <zb(at)cybertec(dot)at> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Michael Meskes <meskes(at)postgresql(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>, Hans-Juergen Schoenig <hs(at)cybertec(dot)at> |
Subject: | Re: ECPG FETCH readahead |
Date: | 2010-06-24 09:27:56 |
Message-ID: | 4C23251C.8060403@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2010-06-24 11:04 keltezéssel, Heikki Linnakangas írta:
> On 24/06/10 10:27, Böszörményi Zoltán wrote:
>> And this readahead is not on by default, it's only activated
>> by "ecpg -r fetch_readahead".
>
> Is there a reason not to enable it by default? I'm a bit worried that
> it will receive no testing if it's not always on.
Because in the first step I wanted to minimize the impact
on regression test stderr results. This is what I mentioned
in the initial mail, I stuck to the original wording of ecpg_log()
messages in the split-up parts of the original ECPGdo() and
ecpg_execute() exactly for this reason. The usual policy for
ecpg_log() is to report the function name where it was issued.
I was also thinking about a new feature for pg_regress,
to compare stdout results of two regression tests automatically
so a difference can be reported as an error. It would be good
for automated testing of features in ECPG that can be toggled,
like auto-prepare and fetch readahead. It might come in handy
in other subsystems, too.
Best regards,
Zoltán Böszörményi
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2010-06-24 11:04:37 | Re: TCP keepalive support for libpq |
Previous Message | Heikki Linnakangas | 2010-06-24 09:04:30 | Re: ECPG FETCH readahead |