Re: [HACKERS] Increase Vacuum ring buffer.

Поиск
Список
Период
Сортировка
От Claudio Freire
Тема Re: [HACKERS] Increase Vacuum ring buffer.
Дата
Msg-id CAGTBQpZsAGWr8bcLZAqLR87F=B9G4vGSkGXUrqQ9hqhNkYG=ZQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Increase Vacuum ring buffer.  (Sokolov Yura <funny.falcon@postgrespro.ru>)
Ответы Re: [HACKERS] Increase Vacuum ring buffer.  (Sokolov Yura <funny.falcon@postgrespro.ru>)
Список pgsql-hackers
On Fri, Jul 21, 2017 at 2:41 PM, Sokolov Yura
<funny.falcon@postgrespro.ru> wrote:
>
> My friend noticed, that I didn't said why I bother with autovacuum.
> Our customers suffers from table bloating. I've made synthetic
> bloating test, and started experiments with modifying micro- and
> auto-vacuum. My first attempts were to update FSM early (both in
> micro and autovacuum) and update it upto root, not only low level.

This FSM thing is probably not a bad idea as well.

We're forced to run regular manual vacuums because for some tables
autovacuums seems to never be enough, no matter how it's configured,
mostly because it gets canceled all the time. These are high-churn,
huge tables, so vacuuming them takes hours or days, there's always
someone with a conflicting lock at some point that ends up canceling
the autovacuum task.

The above paragraph triggered me to go check, and it seems in those
cases the FSM never gets vacuumed. That's probably not a good thing,
but I don't see how to vacuum the FSM after a cancel. So vacuuming the
FSM from time to time during long-running vacuums seems like a good
idea at this point.



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: [HACKERS] Buildfarm failure and dubious coding in predicate.c
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: [HACKERS] segfault in HEAD when too many nested functions call