Horton

Re: ECPG FETCH readahead

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Boszormenyi Zoltan <zb@cybertec.at>
Cc: Michael Meskes <meskes@postgresql.org>, PG Hackers <pgsql-hackers@postgresql.org>, Hans-Juergen Schoenig <hs@cybertec.at>
Date: 2010-06-23T20:42:37Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix some "translator:" comments mangled by pgindent

  2. Make sure float4in/float8in accept all standard spellings of "infinity".

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@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + None of us is going to be here forever. +