Date: Thu, 11 Jan 2007 15:16:09 -0600
From: "Jim C. Nasby" <jim@nasby.net>
To: Tom Lane <tgl@sss.pgh.pa.us>, Kim <kim@myemma.com>,
	pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] unusual performance for vac following 8.2 upgrade
Message-ID: <20070111211609.GT36267@nasby.net>
References: <45A671CD.1050706@myemma.com> <27939.1168539652@sss.pgh.pa.us>
	<45A68C74.4080405@myemma.com> <28949.1168544710@sss.pgh.pa.us>
	<20070111194928.GC10464@alvh.no-ip.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20070111194928.GC10464@alvh.no-ip.org>
User-Agent: Mutt/1.5.13 (2006-08-11)

On Thu, Jan 11, 2007 at 04:49:28PM -0300, Alvaro Herrera wrote:
> Tom Lane wrote:
> 
> > 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.
> 
> (2) seems a perfectly reasonably answer, but ISTM (1) would be good to
> have anyway (at least in HEAD).

Actually, I'd rather see the impact #1 has before adding #2... If #1
means we're good for even someone with 10M relations, I don't see much
point in #2.

BTW, we're now starting to see more users with a large number of
relations, thanks to partitioning. It would probably be wise to expand
test coverage for that case, especially when it comes to performance.
-- 
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)