Received: from localhost (unknown [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id 1ADBC9F9941
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 15:20:35 -0300 (ADT)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024)
	with ESMTP id 10821-01 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 21 Sep 2007 15:20:30 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from web30009.mail.mud.yahoo.com (web30009.mail.mud.yahoo.com
	[209.191.69.26]) by postgresql.org (Postfix) with SMTP id AF7A89F9919
	for <pgsql-performance@postgresql.org>;
	Fri, 21 Sep 2007 15:20:31 -0300 (ADT)
Received: (qmail 2070 invoked by uid 60001); 21 Sep 2007 18:20:30 -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:MIME-Version:Content-Type:Message-ID;
	b=FwOE/XC0oyJJVpvCF68Kml1I30nhIQBgHhz+S1SON6bzS4dalPSD8FnvINn05lkBsb/U21X097cdovOtQDqbNnjECLG5xwyE2dVT7T14NTvNS06GlZ0OkzxgZBUfk6P2ZNWuPPHh0QnD4KVUq5H4HiVZN5hCn2+lq2858HxAdIw=;
X-YMail-OSG: 
 xzkj5QcVM1lUJ6I_jdPJasXZJfkG7842gmqd3wTzf0ew6gbylRWipFFBLz5aEaeHpg--
Received: from [68.142.201.149] by web30009.mail.mud.yahoo.com via HTTP;
	Fri, 21 Sep 2007 11:20:30 PDT
X-Mailer: YahooMailRC/651.50 YahooMailWebService/0.7.134
Date: Fri, 21 Sep 2007 11:20:30 -0700 (PDT)
From: brauagustin-susc@yahoo.com.ar
Subject: Re: Low CPU Usage
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	pgsql-performance@postgresql.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1311541771-1190398830=:746"
Message-ID: <582823.746.qm@web30009.mail.mud.yahoo.com>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200709/378
X-Sequence-Number: 26923

--0-1311541771-1190398830=:746
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> Exactly how are you arriv=
ing at those timings you're reporting to us?=0A =0AI have noticed this in a=
 daly process I run which involves normally 45 minutes and with the new ser=
ver takes 1:40.=0A=0ASome 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 the=
n compare disk access.=0ASELECT *=0AFROM fact_ven_renta fvr, dim_producto_s=
td_producto dpp=0AWHERE=0A  fvr.producto_std_producto_sk =3D dpp.producto_s=
k=0A =0Afact_ven_renta has 136316 rows=0Adim_producto_std_producto has 3669=
 rows=0A=0A=0A=0AI have made all possible combinations pgadmin (running in =
the same server each query, in the old one, in the new one), without differ=
ence  and I only retrieve the first 100 records (I didn't count the network=
 time in any case).=0ABut the weird thing is running the query in the new s=
erver the are many disk access and cpu usage. And with other applications i=
n the same server are a lot of disks access.=0A=0A=0A=0A=0A=0A=0A      Segu=
=ED de cerca a la Selecci=F3n Argentina de Rugby en el Mundial de Francia 2=
007.=0Ahttp://ar.sports.yahoo.com/mundialderugby
--0-1311541771-1190398830=:746
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman, new york, times, serif;=
font-size:12pt"><div style=3D"font-family: times new roman,new york,times,s=
erif; font-size: 12pt;"><div style=3D"font-family: times new roman,new york=
,times,serif; font-size: 12pt;"><div>&gt; That's not what it looks like bas=
ed on the EXPLAIN ANALYZE output.<br>&gt; It looks like run time dropped fr=
om two seconds to half a second.<br> <br>&gt; It seems as though you either=
 have a network delay delivering the results,<br>&gt; or your application i=
s slow to read them.<br><br>&gt; Exactly how are you arriving at those timi=
ngs you're reporting to us?<br> <br>I have noticed this in a daly process I=
 run which involves normally 45 minutes and with the new server takes 1:40.=
<br><br>Some days ago I began to do some tests with no success, then I open=
ed PgAdmin with this simply query to read 2 big tables and then compare dis=
k
 access.<br>SELECT *<br>FROM fact_ven_renta fvr, dim_producto_std_producto =
dpp<br>WHERE<br>&nbsp; fvr.producto_std_producto_sk =3D dpp.producto_sk<br>=
 <br>fact_ven_renta has 136316 rows<br>dim_producto_std_producto has 3669 r=
ows<br></div></div><br>I have made all possible combinations pgadmin (runni=
ng in the same server each query, in the old one, in the new one), without =
difference&nbsp; and I only retrieve the first 100 records (I didn't count =
the network time in any case).<br>But the weird thing is running the query =
in the new server the are many disk access and cpu usage. And with other ap=
plications in the same server are a lot of disks access.<br><br><br></div><=
/div><br>=0A=0A=0A=0A      <hr size=3D1><br><font face=3D"Verdana" size=3D"=
-2">Los referentes m=E1s importantes en compra/venta de autos se juntaron:<=
br>Demotores y Yahoo!.=0AAhora comprar o vender tu auto es m=E1s f=E1cil. <=
br> Visit=E1 http://ar.autos.yahoo.com/</font></body></html>
--0-1311541771-1190398830=:746--