Re: [ADMIN] Excessive growth of pg_attribute and other system tables
В списке pgsql-hackers по дате отправления:
| От | Qingqing Zhou |
|---|---|
| Тема | Re: [ADMIN] Excessive growth of pg_attribute and other system tables |
| Дата | |
| Msg-id | d2i9fa$26n5$1@news.hub.org обсуждение исходный текст |
| Ответ на | Re: [ADMIN] Excessive growth of pg_attribute and other system tables (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
"Tom Lane" <tgl@sss.pgh.pa.us> writes > 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? > Seems this is another question pointing to the inproper setting of "can-be-avoided" shared memory parameters. Maybe we should eliminate GUC parameters related to the FSM. Can we follow Alvaro's idea like spilling some data of FSM into disk while keeping the indices and maybe part of data in the memory? So no free page would be discarded due to no space to record them in FSM? Also, in this handling, efficiency should not be a problem. Regards, Qingqing
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера