Re: Question about speed: Weird Behavior

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(at)softperience(dot)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.
>>>
>>
>> I dont know much about the internals of the protocol used to move data
>> 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(dot)bgf(at)gmail(dot)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
>