Re: Berserk Autovacuum (let's save next Mandrill)

Поиск
Список
Период
Сортировка
От Darafei "Komяpa" Praliaskouski
Тема Re: Berserk Autovacuum (let's save next Mandrill)
Дата
Msg-id CAC8Q8tJf95JHTqmvzLQBv=56X+tNX4j9DMwTStAyRyDpBFbQDQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Berserk Autovacuum (let's save next Mandrill)  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: Berserk Autovacuum (let's save next Mandrill)  (Chris Travers <chris.travers@adjust.com>)
Список pgsql-hackers
The invoking autovacuum on table based on inserts, not only deletes
and updates, seems good idea to me. But in this case, I think that we
can not only freeze tuples but also update visibility map even when
setting all-visible. Roughly speaking  I think vacuum does the
following operations.

1. heap vacuum
2. HOT pruning
3. freezing tuples
4. updating visibility map (all-visible and all-frozen)
5. index vacuum/cleanup
6. truncation

With the proposed patch[1] we can control to do 5 or not. In addition
to that, another proposed patch[2] allows us to control 6.

[1] is committed, [2] nears commit. Seems we have now all the infra to teach autovacuum to run itself based on inserts and not hurt anybody?

... 
[1] https://commitfest.postgresql.org/22/1817/
[2] https://commitfest.postgresql.org/22/1981/


--
Darafei Praliaskouski

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

Предыдущее
От: Darafei Praliaskouski
Дата:
Сообщение: Re: reloption to prevent VACUUM from truncating empty pages at the end of relation
Следующее
От: Julien Rouhaud
Дата:
Сообщение: Re: Ordered Partitioned Table Scans