Received: from localhost (maia-5.hub.org [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id 695119FA249;
	Thu, 11 Jan 2007 19:16:05 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024)
	with ESMTP id 61602-05; Thu, 11 Jan 2007 19:15:54 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from mail01.enterprisedb.com (webmail.enterprisedb.com
	[63.246.7.168])
	by postgresql.org (Postfix) with ESMTP id 3DCC29FA222;
	Thu, 11 Jan 2007 19:15:58 -0400 (AST)
thread-index: Acc11nTmkjlY9JbBQ02Mof95GDoClA==
Received: from [192.168.0.22] ([84.12.155.249]) by mail01.enterprisedb.com
	with Microsoft SMTPSVC(6.0.3790.1830);
	Thu, 11 Jan 2007 18:15:59 -0500
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757
Content-Class: urn:content-classes:message
Importance: normal
Subject: Re: [HACKERS] unusual performance for vac following 8.2upgrade
From: "Simon Riggs" <simon@2ndquadrant.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Kim" <kim@myemma.com>, <pgsql-performance@postgresql.org>,
	<pgsql-hackers@postgresql.org>
In-Reply-To: <5414.1168549900@sss.pgh.pa.us>
References: <45A671CD.1050706@myemma.com> <27939.1168539652@sss.pgh.pa.us>
	<45A68C74.4080405@myemma.com> <28949.1168544710@sss.pgh.pa.us>
	<1168548006.3951.564.camel@silverbirch.site>
	<5414.1168549900@sss.pgh.pa.us>
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Thu, 11 Jan 2007 23:14:34 +0000
Message-ID: <1168557275.3990.49.camel@silverbirch.site>
MIME-Version: 1.0
X-Mailer: Evolution 2.6.0 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 11 Jan 2007 23:16:00.0234 (UTC)
	FILETIME=[74CEECA0:01C735D6]
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200701/193
X-Sequence-Number: 22794

On Thu, 2007-01-11 at 16:11 -0500, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > It's not clear to me how this fix will alter the INSERT issue Kim
> > mentions.
> 
> I didn't say that it would; we have no information on the INSERT issue,
> so I'm just concentrating on the problem that he did provide info on.

OK.

> I'm frankly not real surprised that there are performance issues with
> such a huge pg_class; it's not a regime that anyone's spent any time
> optimizing. 

Yeh, I saw a pg_class that big once, but it just needed a VACUUM.

Temp relations still make pg_class entried don't they? Is that on the
TODO list to change?

-- 
  Simon Riggs             
  EnterpriseDB   http://www.enterprisedb.com