Fetch of multiple rows using ecpg.

From: Marcus Engene <mengpg(at)engene(dot)se>
To: pgsql-hackers-win32(at)postgresql(dot)org
Subject: Fetch of multiple rows using ecpg.
Date: 2004-10-17 19:07:41
Message-ID: 4172C2FD.40204@engene.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32

Hi all.

Yesterday was the first day I ever used PostgreSql, so this might be a
silly question. I am very sorry if this is the wrong forum -- if it is,
please tell me where to go.

I'm looking into a cheap alternative to Oracle for my pro*C-batches.
After discovering ecpg, I've come to realize that it is (in theory)
quite easy to port from pro*c (provided that I find a replacement for
DBMS_ALERT).

In Oracles pro*C, if you declare your bind variables as arrays, pro*c
will read several rows at once. As a network has latency this has an
enormous impact on the performance. However, I did some tests and I
haven't seen any indications that PG does use the arrays. Please have a
look at the log and code example at
http://sespro.net/multrows.txt

Ethereal seems unable to trace on traffic to localhost (a windows
feature according to some texts I found) so this is the only indication
I've got. (Ie that you see one "se_mengtest2() FETCHING..." per read row.

Setup:
The new pg 8pre3 on windows XP. Client on the same machine, Visual
Studio 6 and the ecgp that was included in 8pre3. No mingw/cygwin involved.

I noticed that the EXEC SQL DECLARE translated into a call chain like:
ECPGdo()->create_statement()->ECPGget_variable()
ECGPget_variable() sets arrsize to a correct 200 (SQL_ARRAY_SIZE).

Later when EXEC SQL FETCH makes a call to...
PQexec()->PQexecFinish()->PQgetResult()->pqParseInput3()
...there seems to be a loop fetching the tuples. This I conclude that it
is the server that doesn't send more than one row? Is this true? How can
I make it? Is this platform dependent? Is there a interfaces maillist
more eager to listen to this than you are? :-)

While we are at it, has someone experimented with converting the
PostgreSql protocol to ASN.1::PER? esnacc claims to have support for PER
nowdays (in the latest version). Low bandwidth use is valuable for
obvious reasons when reading a set and it looked that libpq::fe-misc.c
does not care much about saving bandwidth.

All the best,
Marcus

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Tom Lane 2004-10-17 20:05:09 Re: Win32 & NLS
Previous Message Tom Lane 2004-10-17 18:44:57 Re: [pgsql-hackers-win32] Win32 & NLS