>> > That's not what it looks like based on the EXPLAIN ANALYZE output.
>> > It looks like run time dropped from two seconds to half a second.
>>
>> > It seems as though you either have a network delay delivering the results,
>> > or your application is slow to read them.
>>
>> > Exactly how are you arriving at those timings you're reporting to us?
>>
>> I have noticed this in a daly process I run which involves normally 45 minutes and with the new server takes 1:40.
>>
>> Some days ago I began to do some tests with no success, then I opened PgAdmin with this simply query to read 2 big tables and then compare disk access.
>> SELECT *
>> FROM fact_ven_renta fvr, dim_producto_std_producto dpp
>> WHERE
>> fvr.producto_std_producto_sk = dpp.producto_sk
>>
>> fact_ven_renta has 136316 rows
>> dim_producto_std_producto has 3669 rows
>Run the tests from psql on the same server. As Kevin pointed out, the _server_ is faster, but it appears as if the connection between PGadmin and this new server is slower somehow.
It runs quickly!!! But I don't know how to compare because looks like it retrieve fields by demand, when I put ctrl+end (go to the last record) it use a lot of CPU and disk, run quickly anyway.
Correct me if am I wrong but, executing PgAdmin in the same server there aren't networks delays!
And when the server is processing the query there isn't network traffic because is processing the result.
> Are you sure of your speed/duplex settings on the network side? That's
> the most common cause of this kind of thing in my experience. Try doing
> a raw FTP transfer between the client and server and see if you get the
> speed you should.
This isn't a dedicated database server, client application and server are running in the same machine!!!
I have stop the client application too with same results.
Anyway I will do some network test to find a solution.
>> > It looks like run time dropped from two seconds to half a second.
>>
>> > It seems as though you either have a network delay delivering the results,
>> > or your application is slow to read them.
>>
>> > Exactly how are you arriving at those timings you're reporting to us?
>>
>> I have noticed this in a daly process I run which involves normally 45 minutes and with the new server takes 1:40.
>>
>> Some days ago I began to do some tests with no success, then I opened PgAdmin with this simply query to read 2 big tables and then compare disk access.
>> SELECT *
>> FROM fact_ven_renta fvr, dim_producto_std_producto dpp
>> WHERE
>> fvr.producto_std_producto_sk = dpp.producto_sk
>>
>> fact_ven_renta has 136316 rows
>> dim_producto_std_producto has 3669 rows
>Run the tests from psql on the same server. As Kevin pointed out, the _server_ is faster, but it appears as if the connection between PGadmin and this new server is slower somehow.
It runs quickly!!! But I don't know how to compare because looks like it retrieve fields by demand, when I put ctrl+end (go to the last record) it use a lot of CPU and disk, run quickly anyway.
Correct me if am I wrong but, executing PgAdmin in the same server there aren't networks delays!
And when the server is processing the query there isn't network traffic because is processing the result.
> Are you sure of your speed/duplex settings on the network side? That's
> the most common cause of this kind of thing in my experience. Try doing
> a raw FTP transfer between the client and server and see if you get the
> speed you should.
This isn't a dedicated database server, client application and server are running in the same machine!!!
I have stop the client application too with same results.
Anyway I will do some network test to find a solution.
El Mundial de Rugby 2007
Las últimas noticias en Yahoo! Deportes:
http://ar.sports.yahoo.com/mundialderugby
