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








Seguí de cerca a la SelecciónArgentina de Rugby en el Mundial de Francia 2007.
http://ar.sports.yahoo..com/mundialderugby

In response to brauagustin-susc@yahoo.com.ar:

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

That's pretty odd. If you use \timing in psql, you can get execution
time for each query, if it helps you track things down.

> Correct me if am I wrong but, executing PgAdmin in the same server there aren't networks delays!

Not network, no. But the results of your explains seem to show that the
query is executing much faster on the new system than the old, so the
problem still becomes, "what is happening after the query completes that
is so slow?" It's just that networking is ruled out.


--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran@collaborativefusion.com
Phone: 412-422-3463x4023

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly