pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Böszörményi Zoltán <zb@cybertec.at>
To: Bruce Momjian <bruce@momjian.us>
Cc: Michael Meskes <meskes@postgresql.org>
Cc: PG Hackers <pgsql-hackers@postgresql.org>
Cc: Hans-Juergen Schoenig <hs@cybertec.at>
Subject: Re: ECPG FETCH readahead
Date: Thu, 24 Jun 2010 09:27:57 +0200
Message-ID: <4C2308FD.1090300@cybertec.at> (raw)
In-Reply-To: <201006232042.o5NKgb503695@momjian.us>
References: <201006232042.o5NKgb503695@momjian.us>

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




view thread (69+ messages)  latest in thread

Message-ID: <4C2308FD.1090300@cybertec.at>
Permalink:  ../4C2308FD.1090300@cybertec.at/
Also on:    postgresql.org/message-id/4C2308FD.1090300@cybertec.at

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: zb@cybertec.at, bruce@momjian.us, meskes@postgresql.org, hs@cybertec.at
  Subject: Re: ECPG FETCH readahead
  In-Reply-To: <4C2308FD.1090300@cybertec.at>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox