| From: | Darafei "Komяpa" Praliaskouski <me(at)komzpa(dot)net> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Berserk Autovacuum (let's save next Mandrill) |
| Date: | 2019-04-06 07:56:16 |
| Message-ID: | CAC8Q8tJf95JHTqmvzLQBv=56X+tNX4j9DMwTStAyRyDpBFbQDQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
Support me: http://patreon.com/komzpa
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julien Rouhaud | 2019-04-06 09:06:30 | Re: Ordered Partitioned Table Scans |
| Previous Message | Darafei Praliaskouski | 2019-04-06 07:53:07 | Re: reloption to prevent VACUUM from truncating empty pages at the end of relation |