Rainer Bauer wrote:
It's not immediately clear why pgAdmin would have the same issue,
though, because AFAIK it doesn't rely on ODBC.
No it doesn't. That's the reason I used it to verify the behaviour.
But I remember Dave Page mentioning using a virtual list control to display
the results and that means a round trip for every tuple.
pgAdmin's Query Tool (which I assume you're using), uses an async query
via libpq to populate a virtual table behind the grid. The query
handling can be seen in pgQueryThread::execute() at
http://svn.pgadmin.org/cgi-bin/viewcvs.cgi/trunk/pgadmin3/pgadmin/db/pgQueryThread.cpp?rev=6082&view=markup
When the query completes, a dataset object (basically a wrapper around a
PGresult) is attached to the grid control. As the grid renders each
cell, it requests the value to display which results in a call to
PQgetValue. This is how the old display time was eliminated - cells are
only rendered when they become visible for the first time, meaning that
the query executes in pgAdmin in the time it takes for the async query
to complete plus (visible rows * visible columns)PQgetValue calls.
I don't think it's a Windows-specific problem, because psql is doing the job
blindingly fast. The problem lies in the way my application is coded. See the
response to Dimitri for details.
I don't see why pgAdmin should be slow though - it should be only
marginally slower than psql I would think (assuming there are no thinkos
in our code that none of use ever noticed).
Regards, Dave.
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
