Received: from maia.hub.org (maia-2.hub.org [200.46.204.251])
	by mail.postgresql.org (Postfix) with ESMTP id 4907163282E
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Thu, 15 Jul 2010 15:48:19 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia,
	port 10024) with ESMTP id 42174-02
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Thu, 15 Jul 2010 18:48:11 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mm-mailstore02.merit.edu (mm-mailstore02.merit.edu
	[207.74.184.19])
	by mail.postgresql.org (Postfix) with ESMTP id 85C5963267E
	for <pgsql-performance@postgresql.org>;
	Thu, 15 Jul 2010 15:48:10 -0300 (ADT)
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mm-mailstore02.merit.edu (Postfix) with ESMTP id D53386801412;
	Thu, 15 Jul 2010 14:48:09 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mm-mailstore02.merit.edu
Received: from mm-mailstore02.merit.edu ([127.0.0.1])
	by localhost (mm-mailstore02.merit.edu [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id y6XQViSypHsX; Thu, 15 Jul 2010 14:48:04 -0400 (EDT)
Received: from mm-mailstore02.merit.edu (mm-mailstore02.merit.edu
	[10.108.2.25])
	by mm-mailstore02.merit.edu (Postfix) with ESMTP id E82376800BBB;
	Thu, 15 Jul 2010 14:48:04 -0400 (EDT)
Date: Thu, 15 Jul 2010 14:48:04 -0400 (EDT)
From: Patrick Donlin <pdonlin@oaisd.org>
To: Merlin Moncure <mmoncure@gmail.com>
Cc: pgsql-performance@postgresql.org
Message-ID: 
 <1045407518.13317091279219684833.JavaMail.root@mm-mailstore02.merit.edu>
In-Reply-To: <AANLkTinBo6FyQvnDr9hfFN1T2WfpxCQf7uQKv0ajIvDq@mail.gmail.com>
Subject: Re: Identical query slower on 8.4 vs 8.3
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_448990_767340079.1279219684831"
X-Originating-IP: [64.9.158.13]
X-Mailer: Zimbra 5.0.21_GA_3150.RHEL5_64 (ZimbraWebClient - FF3.0
	(Mac)/5.0.21_GA_3150.RHEL5_64)
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-4.199 tagged_above=-10 required=5
	tests=BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3
X-Spam-Level: 
X-Archive-Number: 201007/245
X-Sequence-Number: 39634

------=_Part_448990_767340079.1279219684831
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Thanks everyone for the input so far, Merlin's comment about the network gave me one of those duh moments since I have been running these queries remotely using pgadmin. I will experiment with this more tomorrow/Monday along with the other suggestions that have been posted to hopefully narrow it down. Running the query from my webserver yielded much better times, but from a quick look it seems my 8.4 server is still a bit slower. I will share more details as I dig into it more tomorrow or Monday. 

-Patrick 

----- Original Message ----- 
From: "Merlin Moncure" <mmoncure@gmail.com> 
To: "Patrick Donlin" <pdonlin@oaisd.org> 
Cc: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>, pgsql-performance@postgresql.org 
Sent: Thursday, July 15, 2010 12:04:13 PM GMT -05:00 US/Canada Eastern 
Subject: Re: [PERFORM] Identical query slower on 8.4 vs 8.3 

your plans are identical as is the runtime basically. this means you 
might want to consider the following possibilities: 
*) operator error :-) 
*) cache effects 
*) environmental factors on the server at the time 
*) network/client issues 

I say network issues because if your explain analyze (which actually 
does run the entire query) is significantly faster than the full 
query, then we have to consider that the formatting and transfer of 
the data back to the client (even if it's on the same box) becomes 
suspicious. If you've eliminated other possibilities, try running 
other big, trivially planned, mucho result returning queries (like 
select * from table) on both servers and comparing times. 

merlin 

------=_Part_448990_767340079.1279219684831
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><=
div style=3D'font-family: Arial; font-size: 12pt; color: #000000'>Thanks ev=
eryone for the input so far, Merlin's comment about the network gave me one=
 of those duh moments since I have been running these queries remotely usin=
g pgadmin. I will experiment with this more tomorrow/Monday along with the =
other suggestions that have been posted to hopefully narrow it down. Runnin=
g the query from my webserver yielded much better times, but from a quick l=
ook it seems my 8.4 server is still a bit slower. I will share more details=
 as I dig into it more tomorrow or Monday.<br><br>-Patrick<br><br>----- Ori=
ginal Message -----<br>From: "Merlin Moncure" &lt;mmoncure@gmail.com&gt;<br=
>To: "Patrick Donlin" &lt;pdonlin@oaisd.org&gt;<br>Cc: "Kevin Grittner" &lt=
;Kevin.Grittner@wicourts.gov&gt;, pgsql-performance@postgresql.org<br>Sent:=
 Thursday, July 15, 2010 12:04:13 PM GMT -05:00 US/Canada Eastern<br>Subjec=
t: Re: [PERFORM] Identical query slower on 8.4 vs 8.3<br><br>your plans are=
 identical as is the runtime basically. &nbsp;this means you<br>might want =
to consider the following possibilities:<br>*) operator error :-)<br>*) cac=
he effects<br>*) environmental factors on the server at the time<br>*) netw=
ork/client issues<br><br>I say network issues because if your explain analy=
ze (which actually<br>does run the entire query) is significantly faster th=
an the full<br>query, then we have to consider that the formatting and tran=
sfer of<br>the data back to the client (even if it's on the same box) becom=
es<br>suspicious. &nbsp;If you've eliminated other possibilities, try runni=
ng<br>other big, trivially planned, mucho result returning queries (like<br=
>select * from table) on both servers and comparing times.<br><br>merlin<br=
></div></body></html>
------=_Part_448990_767340079.1279219684831--