Re: [ADMIN] Excessive growth of pg_attribute and other system tables
От | Matthew T. O'Connor |
---|---|
Тема | Re: [ADMIN] Excessive growth of pg_attribute and other system tables |
Дата | |
Msg-id | 424C6897.1050206@zeut.net обсуждение исходный текст |
Ответ на | Re: [ADMIN] Excessive growth of pg_attribute and other system tables (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: