Re: [ADMIN] Excessive growth of pg_attribute and other system tables - Mailing list pgsql-hackers

From Matthew T. O'Connor
Subject Re: [ADMIN] Excessive growth of pg_attribute and other system tables
Date
Msg-id 424C6897.1050206@zeut.net
Whole thread Raw
In response to Re: [ADMIN] Excessive growth of pg_attribute and other system tables  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:

>Steve Crawford <scrawford@pinpointresearch.com> writes:
>  
>
>>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?
>>>      
>>>
>
>  
>
>>Results time. FSM settings were too small but the real problem seems 
>>to be that pg_autovacuum isn't getting the job done.
>>    
>>
>
>The light just went on ... system catalog updates don't generate
>statistics reports.  Hence, autovacuum doesn't know any work is needed.
>
>Should we fix that, or change autovacuum to special-case the system
>catalogs somehow, or ???
>  
>

Really?!?!?!?  Wow, if that is true, that is a big gaping hole in the 
autovacuum design.  Is that true for all types of system catalog 
updates?  The reason I ask is that the stats system is reporting at 
least some of activity on pg_attribute in this example.  So why would it 
report some but not all?

Is there any chance fixing the stats system to include system catalog 
updates would be simple enough to put into the 8.0.x branch?  I don't 
know a another way for pg_autovacuum know if it's time for an vacuum.

Hopefully the autovacuum in 8.1 will be a fairly different animal.



pgsql-hackers by date:

Previous
From: Steve Crawford
Date:
Subject: Re: [ADMIN] Excessive growth of pg_attribute and other system tables
Next
From: Tom Lane
Date:
Subject: Re: [ADMIN] Excessive growth of pg_attribute and other system tables