Re: How to prevent jdbc from sending any results back to the client ?

I know that the backend process caches the pages in shared buffers so I set
up a warm up phase before I start benchmarking.

The thing is that whenever I use psql to execute my query it takes some
seconds and then it returns with the results.
For the case of jdbc driver, it returns imediately. Shouldn't it block for
some seconds too and then return ?

On Sun, Apr 20, 2014 at 8:53 PM, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:

> Dimitris,
>
> No it does not do query caching. The backend does cache so typically the
> first query will take a while, then subsequent queries will take much less
> time as the data is in RAM.
>
> Dave Cramer
>
> dave.cramer(at)credativ(dot)ca
> http://www.credativ.ca
>
>
> On 20 April 2014 14:46, Dimitris Karampinas <dkarampin(at)gmail(dot)com> wrote:
>
>> Thanks, EXPLAIN ANALYSE might be an option for me.
>>
>> One more question, because in certain cases I get strange results.
>> Does jdbc do any kind of result or query caching by default ?
>>
>> -dk
>>
>>
>> On Sun, Apr 20, 2014 at 2:22 AM, Dave Cramer <pg(at)fastcrypt(dot)com> wrote:
>>
>>> Dimitris,
>>>
>>> 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
>>>
>>> Dave
>>>
>>> Dave Cramer
>>>
>>> dave.cramer(at)credativ(dot)ca
>>> http://www.credativ.ca
>>>
>>>
>>> On 19 April 2014 15:02, Sehrope Sarkuni <sehrope(at)jackdb(dot)com> wrote:
>>>
>>>> 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.
>>>>
>>>> [1]: http://www.postgresql.org/docs/9.3/static/sql-explain.html
>>>>
>>>> Regards,
>>>> Sehrope Sarkuni
>>>> Founder & CEO | JackDB, Inc. | http://www.jackdb.com/
>>>>
>>>> On Apr 19, 2014, at 2:48 PM, Dimitris Karampinas <dkarampin(at)gmail(dot)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 ?
>>>>
>>>> Cheers,
>>>> Dimitris
>>>>
>>>>
>>>
>>
>