Re: Question about speed: Weird Behavior
От | Israel Ben Guilherme Fonseca |
---|---|
Тема | Re: Question about speed: Weird Behavior |
Дата | |
Msg-id | BANLkTik5zXqJbVZ_K87KntnRsORWTVmvnw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Question about speed: Weird Behavior (Radosław Smogura <rsmogura@softperience.eu>) |
Список | pgsql-jdbc |
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,
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: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.I dont know much about the internals of the protocol used to move dataWhen 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 theshould definitely be faster than select count(*), since count(*) cant
query returns as soon as the first row has arrived, then select *Links:
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
------
[1] mailto:israel.bgf@gmail.com
Regards,
Radek
В списке pgsql-jdbc по дате отправления: