Re: Excessive growth of pg_attribute and other system tables

On Monday 21 March 2005 11:40 am, Tom Lane wrote:

> However, given that there are 9334 tuples in 82282 pages, I'd say
> that autovacuum has already failed Steve rather badly :-(. There
> shouldn't be more than a couple hundred pages given that number of
> rows. Perhaps the FSM settings are too small?

Yup, we've pretty well established that my fsm settings were way too
low. I've bumped them up:
max_fsm_relations from 1,000 to 3,000
max_fsm_pages from 20,000 to 1,000,000

The slight expenditure of a few meg of RAM on a 4G ram machine will
hurt me far less than the incomplete vacuums. I have to schedule some
low-volume time to restart the server and vacum-full before I'll see
the result.

Just to make sure I'm understanding things correctly this time...I
originally (mis)understood these as settings related to resources
used _during_ vacuuming. My current understanding is that they are
basically pointers that track what space is available for reclamation
by vaccum and that the amount of fsm resources required depends on
both frequency of vacuums and volume of updates/deletes.

Questions:

1) Is my revised understanding correct?

And if the answer to 1 is yes...

2) What happens with all that free-space information at server restart
(ie. does a server restart lead to dead-tuple leakage)?

3) Is (or should) there be logging of the fact that a server has run
out of resources to track dead space?

4) Is there a way to query what proportion of the fsm resources are in
use and would access to that info be useful to the autovacuum daemon
or a system tuner?

Cheers,
Steve