Skip site navigation (1) Skip section navigation (2)

Re: 8.0.3 pg_autovacuum doesn't clear out stats table?

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Robin Iddon <robin(at)edesix(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: 8.0.3 pg_autovacuum doesn't clear out stats table?
Date: 2006-02-23 23:49:45
Message-ID: 20060223234945.GN2068@pervasive.com (view raw or flat)
Thread:
Lists: pgsql-admin
On Thu, Feb 23, 2006 at 11:44:47PM +0000, Robin Iddon wrote:
> 
> >
> >In fact I just noticed that the number of stats tuples just climbed 
> >from 1236 to 2634.  The ins/del counts are still zero.  I ran analyze 
> >and the update counter went up only by 1232.  For pg_autovacuum to 
> >vacuum this table I need (2*2634)+1000 = 6268 updates, which is never 
> >going to happen.
> 
> At least not before the number of tuples has climbed to beyond that 
> count based on my experience to date!

I think you're confusing tuples and rows. Everytime you update a row,
you create a new tuple. As you've seen, every time you run analyze,
~1400 rows are being updated, which means 1400 new tuples. So as long as
pg_autovacuum stays running long enough, it will notice that
pg_statistics needs to be vacuumed. Note that it's critical that
pg_autovac stay running; it keeps the counts of how many tuples every
table has in memory, so if it gets shutdown before enough updates
accumulate, the count re-starts from scratch. I'm not certain if the
builtin vacuum in 8.1 solves that problem or not.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby(at)pervasive(dot)com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

In response to

pgsql-admin by date

Next:From: Robin IddonDate: 2006-02-23 23:49:46
Subject: Re: 8.0.3 pg_autovacuum doesn't clear out stats table?
Previous:From: Robin IddonDate: 2006-02-23 23:44:47
Subject: Re: 8.0.3 pg_autovacuum doesn't clear out stats table?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group