From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Boszormenyi Zoltan <zb(at)cybertec(dot)at> |
Cc: | 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-23 20:42:37 |
Message-ID: | 201006232042.o5NKgb503695@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ None of us is going to be here forever. +
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-06-23 20:54:00 | Re: Cannot cancel the change of a tablespace |
Previous Message | Robert Haas | 2010-06-23 18:36:28 | Re: [BUGS] Server crash while trying to read expression using pg_get_expr() |