Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 43E3D63804E for ; Thu, 24 Jun 2010 04:27:26 -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 17846-02-8; Thu, 24 Jun 2010 07:27:18 +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 0166A636042; Thu, 24 Jun 2010 04:27:12 -0300 (ADT) Received: from localhost.localdomain (unknown [84.115.25.80]) by mail.cybertec.at (Postfix) with ESMTP id B4C5D5FC1B4; Thu, 24 Jun 2010 09:18:38 +0200 (CEST) Message-ID: <4C2308FD.1090300@cybertec.at> Date: Thu, 24 Jun 2010 09:27:57 +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: Bruce Momjian CC: Michael Meskes , PG Hackers , Hans-Juergen Schoenig Subject: Re: ECPG FETCH readahead References: <201006232042.o5NKgb503695@momjian.us> In-Reply-To: <201006232042.o5NKgb503695@momjian.us> 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.011 tagged_above=-5 required=5 tests=BAYES_40=-0.001, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201006/1273 X-Sequence-Number: 164903 Hi, 2010-06-23 22:42 keltezéssel, Bruce Momjian írta: > Boszormenyi Zoltan wrote: > >> Hi, >> >> we improved ECPG quite a lot in 9.0 because we worked and >> still working with an Informix to PostgreSQL migration project. >> >> We came across a pretty big performance problem that can be seen in >> every "naive" application that uses only FETCH 1, FETCH RELATIVE >> or FETCH ABSOLUTE. These are almost the only FETCH variations >> usable in Informix, i.e. it doesn't have the grammar for fetching N rows >> at once. Instead, the Client SDK libraries do caching themselves >> behind the scenes to reduce network turnaround time. >> > I assume our ecpg version supports>1 fetch values, even in Informix > mode. Does it make sense to add lots of code to our ecpg then? > I think, yes, it does make sense. Because we are talking about porting a whole lot of COBOL applications. The ESQL/C or ECPG connector was already written the Informix quirks in mind, so it fetches only one record at a time passing it to the application. And similar performance is expected from ECPG - which excpectation is not fulfilled currently because libecpg doesn't do the same caching as ESQL/C does. And FYI, I haven't added a whole lot of code, most of the code changes in the patch is execute.c refactoring. ECPGdo() was split into several functions, the new parts are still doing the same things. I can make the test case much smaller, I only needed to test crossing the readahead window boundary. This would also make the patch much smaller. And this readahead is not on by default, it's only activated by "ecpg -r fetch_readahead". Best regards, Zoltán Böszörményi