Re: FSM rewrite committed, loose ends

Поиск
Список
Период
Сортировка
От Gregory Stark
Тема Re: FSM rewrite committed, loose ends
Дата
Msg-id 87d4ildb8k.fsf@oxford.xeocode.com
обсуждение исходный текст
Ответ на Re: FSM rewrite committed, loose ends  (Dimitri Fontaine <dfontaine@hi-media.com>)
Список pgsql-hackers
Dimitri Fontaine <dfontaine@hi-media.com> writes:

> Question for the slow readers: this new FSM scheme being dynamic, it's no 
> longer possible to have table bloat, right?
> (where table bloat is full of dead-for-any-transaction tuples, and you have to 
> CLUSTER or VACUUM FULL to be able to reuse the space it takes)

What it does mean is that after a plain old VACUUM *all* the dead space in the
table will be noted and available for reuse. There isn't the risk that your
max_fsm_pages is too small and some of it gets forgotten.

The two headline numbers are percentage (and # bytes) of reusable free space
and percentage of non-reusable free space. The former being the thing to watch
to make sure you're vacuuming frequently enough and the latter being the thing
to watch to understand the impact of long-running transactions.

I don't think we really need to worry about the number of pages, or the
"usable" in the sense of "larger than the average allocation size"
measurements. They're both interesting but not as critical as the bottom-line
number which is how much of the table is being occupied by dead space.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [BUG] pg_ctl restart at the vanilla v8.3.4
Следующее
От: Dimitri Fontaine
Дата:
Сообщение: Re: FSM rewrite committed, loose ends