Re: Berserk Autovacuum (let's save next Mandrill) - Mailing list pgsql-hackers

From Darafei "Komяpa" Praliaskouski
Subject Re: Berserk Autovacuum (let's save next Mandrill)
Date
Msg-id CAC8Q8tJf95JHTqmvzLQBv=56X+tNX4j9DMwTStAyRyDpBFbQDQ@mail.gmail.com
Whole thread Raw
In response to Re: Berserk Autovacuum (let's save next Mandrill)  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Berserk Autovacuum (let's save next Mandrill)
List 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 by date:

Previous
From: Darafei Praliaskouski
Date:
Subject: Re: reloption to prevent VACUUM from truncating empty pages at the end of relation
Next
From: Julien Rouhaud
Date:
Subject: Re: Ordered Partitioned Table Scans