Received: from localhost (maia-3.hub.org [200.46.204.184])
	by postgresql.org (Postfix) with ESMTP id 9560B9FB85A
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 18 May 2007 13:21:47 -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 29246-08 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 18 May 2007 13:21:42 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from is.rice.edu (is.rice.edu [128.42.42.24])
	by postgresql.org (Postfix) with ESMTP id E80E19FB841
	for <pgsql-performance@postgresql.org>;
	Fri, 18 May 2007 13:21:42 -0300 (ADT)
Received: from scan2.mail.rice.edu (scan2.mail.rice.edu [128.42.59.161])
	by is.rice.edu (Postfix) with ESMTP id 550B741820;
	Fri, 18 May 2007 11:21:41 -0500 (CDT)
Received: from is.rice.edu ([128.42.42.24])
	by scan2.mail.rice.edu (scan2.mail.rice.edu [128.42.59.161])
	(amavisd-new, port 10024)
	with ESMTP id 07450-01; Fri, 18 May 2007 11:21:40 -0500 (CDT)
Received: by is.rice.edu (Postfix, from userid 18612)
	id 31C1341822; Fri, 18 May 2007 11:21:39 -0500 (CDT)
Date: Fri, 18 May 2007 11:21:39 -0500
From: Kenneth Marshall <ktm@rice.edu>
To: Liviu Ionescu <ilgb@livius.net>
Cc: pgsql-performance@postgresql.org
Subject: Re: performance drop on 8.2.4, reverting to 8.1.4
Message-ID: <20070518162139.GG7069@it.is.rice.edu>
References: 
 <8C5B026B51B6854CBE88121DBF097A86C39661@ehost010-33.exch010.intermedia.net>
	<00a101c79962$de653d50$653e10ac@ilgvaio>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00a101c79962$de653d50$653e10ac@ilgvaio>
User-Agent: Mutt/1.4.2i
X-Virus-Scanned: by amavis-2.2.1 at scan2.mail.rice.edu
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200705/365
X-Sequence-Number: 24755

On Fri, May 18, 2007 at 06:40:31PM +0300, Liviu Ionescu wrote:
> > under some alignments of the planets 8.1 has similar problems.
> 
> 8.1 might have similar problems, but the point here is different: if what
> was manually tuned to work in 8.1 confuses the 8.2 planner and performance
> drops so much (from 2303 to 231929 ms in my case) upgrading a production
> machine to 8.2 is a risky business. I probably have hundreds of sql
> statements in my application, some of them quite complex, and it is not
> reasonable to check all of them in order to certify them to be 8.2
> compliant.
> 
> regards,
> 
> Liviu
> 
> 
Liviu,

It is arguable, that updating the DB software version in an enterprise
environment requires exactly that: check all production queries on the
new software to identify any issues. In part, this is brought on by the
very tuning that you performed against the previous software. Restore
the 8.1 DB into 8.2. Then run the queries against both versions to
evaluate functioning and timing.

Ken