From: Jim C. Nasby <jim@nasby.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Kim <kim@myemma.com>
To: pgsql-performance@postgresql.org
To: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] unusual performance for vac following 8.2 upgrade
Date: Thu, 11 Jan 2007 15:16:09 -0600
Message-ID: <20070111211609.GT36267@nasby.net> (raw)
In-Reply-To: <20070111194928.GC10464@alvh.no-ip.org>
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>
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)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: jim@nasby.net, tgl@sss.pgh.pa.us, kim@myemma.com, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] unusual performance for vac following 8.2 upgrade
In-Reply-To: <20070111211609.GT36267@nasby.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox