Re: reloption to prevent VACUUM from truncating empty pages at theend of relation

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
Дата
Msg-id 20190304201112.osvneqxzuldxqq4b@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: reloption to prevent VACUUM from truncating empty pages at theend of relation  ("Bossart, Nathan" <bossartn@amazon.com>)
Ответы Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
Список pgsql-hackers
Hi,

On 2019-03-04 20:03:37 +0000, Bossart, Nathan wrote:
> On 3/3/19, 9:23 PM, "Masahiko Sawada" <sawada.mshk@gmail.com> wrote:
> > FWIW, I agree that we have options for vacuum as vacuum
> > command options. But for reloptions, I think if the persistence the
> > setting could be problematic we should not. According to the
> > discussions so far, I think VACUUM_SHRINK_ENABLED is the one option
> > that can be available as both vacuum command option and reloptions.
> > But I'm not sure there is good use case even if we can set
> > DISABLE_INDEX_CLEANUP as reloptions.
> 
> +1
> 
> The DISABLE_INDEX_CLEANUP option is intended to help avoid transaction
> ID wraparound and should not be used as a long-term VACUUM strategy
> for a table.

I'm not quite convinced this is right.  There's plenty sites that
practically can't use autovacuum because it might decide to vacuum the
5TB index because of 300 dead tuples in the middle of busy periods.  And
without an reloption that's not controllable.

- Andres


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

Предыдущее
От: "Bossart, Nathan"
Дата:
Сообщение: Re: reloption to prevent VACUUM from truncating empty pages at theend of relation
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: monitoring CREATE INDEX [CONCURRENTLY]