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@xxxxxxxxxxxxx Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
