You would be better off running queries such as explain analyze which do not return results, but do time the query. Every postgresql client library will have to wait for the results. That is essentially the way the protocol works
The fetch size only comes into play if your are in a transaction. You have to disable auto commit and set the fetch size before executing your query. Otherwise the entire query result will be read and buffered in memory.
An alternative is to run the command as an EXPLAIN ANALYZE[1]. The server will then execute the entire operation but instead of sending back the data it will send the query plan and runtime statistics.
On Apr 19, 2014, at 2:48 PM, Dimitris Karampinas <dkarampin@gmail.com> wrote:
Hi,
I'm working on an academic project and I need to benchmark PostgreSQL.
I'm intersted only about the performance of the DBMS itself and I'm trying to keep things simple in my measurements.
Preferably I'd like to ignore the query results at the client side but jdbc seems to return results even if I don't call next() on the Resultset (is that true ?).
As a consequence, I can't measure acurately a per query execution time since the time I get depends also on the time spent to send the answer (or part of it) to the client.
setFetchSize(1) doesn't seem to help much.
Can I hack the driver and diminish the overhead explained above ?
