To: Kim <kim@myemma.com>
cc: pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org
Subject: Re: unusual performance for vac following 8.2 upgrade 
In-reply-to: <45A68C74.4080405@myemma.com> 
References: <45A671CD.1050706@myemma.com> <27939.1168539652@sss.pgh.pa.us>
	<45A68C74.4080405@myemma.com>
Comments: In-reply-to Kim <kim@myemma.com>
	message dated "Thu, 11 Jan 2007 13:13:56 -0600"
Date: Thu, 11 Jan 2007 14:45:10 -0500
Message-ID: <28949.1168544710@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Kim <kim@myemma.com> writes:
> We were running on 8.1.1 previous to upgrading to 8.2, and yes, we 
> definitely have a heafty pg_class. The inheritance model is heavily used 
> in our schema (the results of the group by you wanted to see are down 
> below).  However, no significant problems were seen with vacs while we 
> were on 8.1.

Odd, because the 8.1 code looks about the same, and it is perfectly
obvious in hindsight that its runtime is about O(N^2) in the number of
relations :-(.  At least that'd be the case if the stats collector
output were fully populated.  Did you have either stats_block_level or
stats_row_level turned on in 8.1?  If not, maybe the reason for the
change is that in 8.2, that table *will* be pretty fully populated,
because now it's got a last-vacuum-time entry that gets made even if the
stats are otherwise turned off.  Perhaps making that non-disablable
wasn't such a hot idea :-(.

What I think we need to do about this is

(1) fix pgstat_vacuum_tabstats to have non-O(N^2) behavior; I'm thinking
of using a hash table for the OIDs instead of a linear list.  Should be
a pretty small change; I'll work on it today.

(2) Reconsider whether last-vacuum-time should be sent to the collector
unconditionally.

Comments from hackers?

			regards, tom lane