Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id A12229FB4D1 for ; Fri, 21 Sep 2007 16:01:43 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 14762-07 for ; Fri, 21 Sep 2007 16:01:33 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from web30014.mail.mud.yahoo.com (web30014.mail.mud.yahoo.com [209.191.69.31]) by postgresql.org (Postfix) with SMTP id E76A59FB223 for ; Fri, 21 Sep 2007 16:01:35 -0300 (ADT) Received: (qmail 2675 invoked by uid 60001); 21 Sep 2007 19:01:34 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ar; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=PlcrwlpXjFouSXGZmliEwoT1UEDlEdv1a5TFy7GWFk0TKPm20tGMCx75xaQipaVX1GkO+tu2xXRLk8TkOz05Hq1GnnNsnZkMFFUxKuCFYXBiCPerVbT8QeYD55hFTo7uB+A7WNHy4UryLJxjjwbUKbFbeRzQO97nECoRp/iGrHk=; X-YMail-OSG: eK.5QJ0VM1kO8ZO1v3Ik4hwTL6CCTXEIU7EdAwFS0eoVbmOwapGDXuv7_LlzMVD40zbWV30OL.P2pQOsX_TXS05CYwp99e_waPhB2fzRiKtY4hMDAib79rnobmWJIQ-- Received: from [209.191.119.123] by web30014.mail.mud.yahoo.com via HTTP; Fri, 21 Sep 2007 12:01:34 PDT X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134 Date: Fri, 21 Sep 2007 12:01:34 -0700 (PDT) From: brauagustin-susc@yahoo.com.ar Subject: Re: Low CPU Usage To: Bill Moran Cc: Kevin Grittner , pgsql-performance@postgresql.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1069428067-1190401294=:2406" Message-ID: <863435.2406.qm@web30014.mail.mud.yahoo.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200709/381 X-Sequence-Number: 26926 --0-1069428067-1190401294=:2406 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >> > That's not what it looks like based on the EXPLAIN ANALYZE output.=0A>= > > It looks like run time dropped from two seconds to half a second.=0A>> = =0A>> > It seems as though you either have a network delay delivering the = results,=0A>> > or your application is slow to read them.=0A>> =0A>> > Exac= tly how are you arriving at those timings you're reporting to us?=0A>> =0A= >> I have noticed this in a daly process I run which involves normally 45 m= inutes and with the new server takes 1:40.=0A>> =0A>> Some days ago I began= to do some tests with no success, then I opened PgAdmin with this simply q= uery to read 2 big tables and then compare disk access.=0A>> SELECT *=0A>> = FROM fact_ven_renta fvr, dim_producto_std_producto dpp=0A>> WHERE=0A>> fv= r.producto_std_producto_sk =3D dpp.producto_sk=0A>> =0A>> fact_ven_renta h= as 136316 rows=0A>> dim_producto_std_producto has 3669 rows=0A=0A>Run the t= ests from psql on the same server. As Kevin pointed out, the _server_ is f= aster, but it appears as if the connection between PGadmin and this new ser= ver is slower somehow.=0A=0AIt runs quickly!!! But I don't know how to comp= are because looks like it retrieve fields by demand, when I put ctrl+end (g= o to the last record) it use a lot of CPU and disk, run quickly anyway.=0AC= orrect me if am I wrong but, executing PgAdmin in the same server there are= n't networks delays!=0AAnd when the server is processing the query there is= n't network traffic because is processing the result.=0A=0A> Are you sure o= f your speed/duplex settings on the network side? That's=0A> the most comm= on cause of this kind of thing in my experience. Try doing=0A> a raw FTP t= ransfer between the client and server and see if you get the=0A> speed you = should.=0AThis isn't a dedicated database server, client application and se= rver are running in the same machine!!!=0AI have stop the client applicatio= n too with same results.=0A=0AAnyway I will do some network test to find a = solution.=0A=0A=0A=0A=0A=0A=0A=0A=0A Segu=ED de cerca a la Selecci=F3n= Argentina de Rugby en el Mundial de Francia 2007.=0Ahttp://ar.sports.yahoo= .com/mundialderugby --0-1069428067-1190401294=:2406 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
>> > That's not what it looks= like based on the EXPLAIN ANALYZE output.
>> > It looks like r= un time dropped from two seconds to half a second.
>>  <= br>>> > It seems as though you either have a network delay deliver= ing the results,
>> > or your application is slow to read them.=
>>
>> > Exactly how are you arriving at those timing= s you're reporting to us?
>>  
>> I have notice= d 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 t= o do some tests with no success, then I opened PgAdmin with this simply quer= y to read 2 big tables and then compare disk access.
>> SELECT *>> FROM fact_ven_renta fvr, dim_producto_std_producto dpp
>&g= t; WHERE
>>   fvr.producto_std_producto_sk =3D dpp.produ= cto_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 n= ew 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 ctr= l+end (go to the last record) it use a lot of CPU and disk, run quickly any= way.
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 expe= rience.  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 th= e same machine!!!
I have stop the client application too with same resul= ts.

Anyway I will do some network test to find a solution.



=0A

El Mundial de Rugby 2007
Las =FAltimas noticias en Yahoo= ! Deportes:
=0Ahttp://ar.sports.yahoo.com/mundialderugby --0-1069428067-1190401294=:2406--