pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Simon Riggs <simon@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kim <kim@myemma.com>
Cc: pgsql-performance@postgresql.org
Cc: pgsql-hackers@postgresql.org
Subject: Re: unusual performance for vac following 8.2 upgrade
Date: Thu, 11 Jan 2007 20:40:06 +0000
Message-ID: <1168548006.3951.564.camel@silverbirch.site> (raw)
In-Reply-To: <28949.1168544710@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>

On Thu, 2007-01-11 at 14:45 -0500, Tom Lane wrote:
> 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?

It's not clear to me how this fix will alter the INSERT issue Kim
mentions. Are those issues connected? Or are you thinking that handling
stats in a tight loop is slowing down other aspects of the system?

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





view thread (21+ messages)  latest in thread

Message-ID: <1168548006.3951.564.camel@silverbirch.site>
Permalink:  ../1168548006.3951.564.camel@silverbirch.site/
Also on:    postgresql.org/message-id/1168548006.3951.564.camel@silverbirch.site

 · 

reply

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: simon@2ndquadrant.com, tgl@sss.pgh.pa.us, kim@myemma.com, pgsql-hackers@postgresql.org
  Subject: Re: unusual performance for vac following 8.2 upgrade
  In-Reply-To: <1168548006.3951.564.camel@silverbirch.site>

* 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