In response to brauagustin-susc@xxxxxxxxxxxx: > > 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. 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. > > > > I have made all possible combinations pgadmin (running in the same server each query, in the old one, in the new one), without difference and I only retrieve the first 100 records (I didn't count the network time in any case). > But the weird thing is running the query in the new server the are many disk access and cpu usage. And with other applications in the same server are a lot of disks access. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@xxxxxxxxxxxxxxxxxxxxxxx Phone: 412-422-3463x4023 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
