I followed the code order.
First warm up, and for last the select * from Curso
No fetch size settings. The code is only what I showed.
--
Another thing, I didn't say it, but if you notice my warm up code do a select in a different table (Pessoa), not Curso. It isn't scanning the Curso table, so it won't do any optimization.
I'll give a look in this TCP/IP autotunning.
--
In the psycopg2 postgresql driver (A python driver), the packages are with constant size (around 8000 bytes), with it the time value are totally constant, no matter if I do loops on the queries, If all this is controlled by kernel/postgres side, I keep wondering why this is so different of the java driver.
I think that I'll ask them too,
Thanks,
2011/6/14 Radosław Smogura
<rsmogura@softperience.eu> On Mon, 13 Jun 2011 21:44:45 -0700, Samuel Gendler wrote:
On Mon, Jun 13, 2011 at 6:07 PM, Israel Ben Guilherme Fonseca wrote: When I use the count, my timings get around of
100 miliseconds.
When I use the select it goes to
30 miliseconds.
around for jdbc, but doesnt this actually make some sense? If the
query returns as soon as the first row has arrived, then select *
should definitely be faster than select count(*), since count(*) cant
return until the entire table has been scanned, whereas select *
returns with the first row received. That, at least, seems like a
likely candidate for the difference between them, no?
--sam
Links:
------
[1] mailto:israel.bgf@gmail.com
Did you ran your queries in above order or did you changed order of queries. Please bear in mind, that if you set fetch size, then cursor approch will be used and not all data will be transferred to client side.
Regards,
Radek