Received: from localhost (maia-5.hub.org [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id 674039FB24E
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri,  9 Feb 2007 11:56:10 -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 29171-03 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri,  9 Feb 2007 11:55:54 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id 542389FB232
	for <pgsql-performance@postgresql.org>;
	Fri,  9 Feb 2007 11:56:00 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id l19Ftv7e029833;
	Fri, 9 Feb 2007 10:55:57 -0500 (EST)
To: Alvaro Herrera <alvherre@commandprompt.com>
cc: minshall@intellicon.biz, pgsql-performance@postgresql.org
Subject: Re: stats collector process high CPU utilization 
In-reply-to: <24717.1171033699@sss.pgh.pa.us> 
References: <45CB5D06.7090004@intellicon.biz> <7994.1170960391@sss.pgh.pa.us>
	<45CB9330.3000603@intellicon.biz> <19935.1170969862@sss.pgh.pa.us>
	<45CB9C4D.30902@intellicon.biz> <20601.1170972476@sss.pgh.pa.us>
	<45CBA443.9090101@intellicon.biz> <7959.1170986672@sss.pgh.pa.us>
	<62089.75.14.32.120.1170994418.squirrel@intellicon.biz>
	<14668.1170995218@sss.pgh.pa.us>
	<20070209142459.GB4253@alvh.no-ip.org>
	<24717.1171033699@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Fri, 09 Feb 2007 10:08:19 -0500"
Date: Fri, 09 Feb 2007 10:55:57 -0500
Message-ID: <29832.1171036557@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200702/101
X-Sequence-Number: 23155

I wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Regarding temp tables, I'd think that the pgstat entries should be
>> getting dropped at some point in both releases.  Maybe there's a bug
>> preventing that in 8.2?

> Hmmm ... I did rewrite the backend-side code for that just recently for
> performance reasons ... could I have broken it?

I did some testing with HEAD and verified that pgstat_vacuum_tabstat()
still seems to do what it's supposed to, so that theory falls down.

Alvaro, could you send Benjamin your stat-file-dumper tool so we can
get some more info?  Alternatively, if Benjamin wants to send me a copy
of his stats file (off-list), I'd be happy to take a look.

			regards, tom lane