Re: ECPG FETCH readahead
Boszormenyi Zoltan <zb@cybertec.at>
From: Böszörményi Zoltán <zb@cybertec.at>
To: Bruce Momjian <bruce@momjian.us>
Cc: Michael Meskes <meskes@postgresql.org>, PG Hackers <pgsql-hackers@postgresql.org>, Hans-Juergen Schoenig <hs@cybertec.at>
Date: 2010-06-24T07:27:57Z
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 →
-
Fix some "translator:" comments mangled by pgindent
- 673b52753489 9.4.0 cited
-
Make sure float4in/float8in accept all standard spellings of "infinity".
- 221e92f64c6e 9.4.0 cited
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