Horton

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

Darafei Komяpa Praliaskouski <me@komzpa.net>

View thread View on postgr.es
From: Darafei "Komяpa" Praliaskouski <me@komzpa.net>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: David Rowley <david.rowley@2ndquadrant.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2019-04-06T07:56:16Z
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

Commits

  1. Further improve stability fix for partition_aggregate test.

  2. Improve stability fix for partition_aggregate test.

  3. Attempt to stabilize partitionwise_aggregate test

  4. Fix race condition in statext_store().

  5. Attempt to fix unstable regression tests, take 2

  6. Attempt to fix unstable regression tests

  7. Trigger autovacuum based on number of INSERTs

  8. Fix upper limit for vacuum_cleanup_index_scale_factor