On Thu, Feb 23, 2006 at 11:34:22PM +0000, Robin Iddon wrote:
> From that I see that the pg_statistics table is never inserted/deleted
> only updated (ins/del counts are 0), and in principle simply analyzing
> doesn't increase the tuple count.
Sure it does. An update in PostgreSQL is essentially identical to a
DELETE followed by an INSERT, due to MVCC.
> I wonder if Matt's suggestion on the vacuum scale is not in fact the
> real issue here. Because my scale is set to 2 (the default) but the
> number of inserts is always zero (unless we create new tables/indexes, I
> think the number of active stats stays the same, no?) and the number of
> updates is at most equal to the number of tuples, we can never get
> enough changes to trigger a vacuum (which would require 2x the number of
> updates). Now any removable rows won't ever get removed.
Sure it well, unless pg_autovacuum can't stay running long enough.
> 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.
Uh, just run analyze 6 times; that should be enough to cause autovacuum
to kick in.
> So I'm going to run with a fractional value of scale for a while and see
> if it makes things any better.
Definately a good idea in any case. You might also consider going to
8.1.3; you'd get built-in autovac which means one less thing to manage,
plus it's default settings are a lot saner (though still too high IMHO).
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461