Re: "analyze" putting wrong reltuples in pg_class

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: "analyze" putting wrong reltuples in pg_class
Дата
Msg-id 6176.1028427201@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: "analyze" putting wrong reltuples in pg_class  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: "analyze" putting wrong reltuples in pg_class  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-bugs
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Is there any way we can warn users when their fsm parameters are too
> small?

Not until we understand what too small is :-(  If anyone's undertaken
any experiments to figure out what an appropriate FSM size setting is,
I'm not aware of it.

The default setting is 10000 pages which would certainly cover all the
free space in 8K*10000 = 80meg of tables, and in practice would cover
significantly more space as long as most of your pages weren't updated
often (and hence didn't have free space to worry about).  But obviously
this number is on the low side for production databases, especially
large ones.  We need to put "pay attention to FSM size" right after
"pay attention to shared_buffers" in the standard list of tuning tips.

Presumably there's some tradeoff curve that says max_fsm_pages should
cover X% of your physical database page count if you update Y% of the
database rows between vacuums.  I'm not sure what the curve looks like
though --- the real issue is how many distinct pages are likely to be
touched when you update so-and-so many rows?

            regards, tom lane

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: Bug #728: Interactions between bytea and character encoding
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Bug #728: Interactions between bytea and character encoding when doing analyze