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

There should be no difference. Can you post an example. Also there is more
caching than just shared buffers. What you are attempting is difficult
On 2014-04-20 3:55 PM, "Dimitris Karampinas" <dkarampin(at)gmail(dot)com> wrote:

> 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
>>>>>
>>>>>
>>>>
>>>
>>
>