Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id B49AE632966 for ; Thu, 24 Jun 2010 06:27:18 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 59981-09; Thu, 24 Jun 2010 09:27:10 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.cybertec.at (mail.cybertec.at [87.118.110.48]) by mail.postgresql.org (Postfix) with ESMTP id 99C01632277; Thu, 24 Jun 2010 06:27:11 -0300 (ADT) Received: from localhost.localdomain (unknown [84.115.25.80]) by mail.cybertec.at (Postfix) with ESMTP id 4C4CC5FC1B4; Thu, 24 Jun 2010 11:18:37 +0200 (CEST) Message-ID: <4C23251C.8060403@cybertec.at> Date: Thu, 24 Jun 2010 11:27:56 +0200 From: =?ISO-8859-1?Q?B=F6sz=F6rm=E9nyi_Zolt=E1n?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Thunderbird/3.0.5 MIME-Version: 1.0 To: Heikki Linnakangas CC: Bruce Momjian , Michael Meskes , PG Hackers , Hans-Juergen Schoenig Subject: Re: ECPG FETCH readahead References: <201006232042.o5NKgb503695@momjian.us> <4C2308FD.1090300@cybertec.at> <4C231F9E.6000102@enterprisedb.com> In-Reply-To: <4C231F9E.6000102@enterprisedb.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.51 tagged_above=-5 required=5 tests=BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201006/1275 X-Sequence-Number: 164905 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