Re: Excessive growth of pg_attribute and other system tables
От | Tom Lane |
---|---|
Тема | Re: Excessive growth of pg_attribute and other system tables |
Дата | |
Msg-id | 29316.1111109568@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Excessive growth of pg_attribute and other system tables (Steve Crawford <scrawford@pinpointresearch.com>) |
Ответы |
Re: Excessive growth of pg_attribute and other system tables
|
Список | pgsql-admin |
Steve Crawford <scrawford@pinpointresearch.com> writes: > On Thursday 17 March 2005 3:51 pm, Tom Lane wrote: >> Do you have the FSM settings set large enough to account for all >> the free space? > max_fsm_pages = 20000 > max_fsm_relations = 1000 That doesn't sound like nearly enough pages for a 2G database. 20000 * 8K = 160MB, so if more than 10% of the pages in your DB are dirty you are going to be leaking free space. You probably want max_fsm_pages up around 250,000. > I just poked through the cluster. I have 6 user databases plus > template0 and template1. Total tables in the cluster has reached > slightly over 1,000 user tables plus all the system tables in the 8 > databases. Does this indicate that I need to increase > max_fsm_relations to greater than the total number of tables in the > cluster? That would be a good plan too. > pg_autovacuum is from 7.4.6 release and is showing periodic vacuums of > the problem tables. I thought that bug was in some release prior to > 7.4.6. Does the bug allow it to show a vacuum taking place but not do > it? I don't recall the details of the changes; you could look at the CVS logs to see what got fixed when. But in any case I think we see the main problem: max_fsm_pages too small. regards, tom lane
В списке pgsql-admin по дате отправления: