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
