Re: Berserk Autovacuum (let's save next Mandrill)
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Darafei Komяpa Praliaskouski <me@komzpa.net>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>, Alvaro Herrera <alvherre@2ndquadrant.com>, Michael Banck <mbanck@gmx.net>, David Rowley <david.rowley@2ndquadrant.com>
Date: 2019-07-23T08:21:29Z
Lists: pgsql-hackers
On Sun, Apr 14, 2019 at 9:59 PM Darafei "Komяpa" Praliaskouski <me@komzpa.net> wrote: >> >> >> >I don't think it's helpful to force emergency vacuuming more >> >frequently; >> >quite the contrary, it's likely to cause even more issues. We should >> >tweak autovacuum to perform freezing more preemtively instead. >> >> I still think the fundamental issue with making vacuum less painful is that the all indexes have to be read entirely. Even if there's not much work (say millions of rows frozen, hundreds removed). Without that issue we could vacuum much more frequently. And do it properly in insert only workloads. > > > Deletion of hundreds of rows on default settings will cause the same behavior now. > If there was 0 updates currently the index cleanup will be skipped. > > https://commitfest.postgresql.org/22/1817/ got merged. This means Autovacuum can have two separate thresholds - the current, on dead tuples, triggering the VACUUM same way it triggers it now, and a new one, on inserted tuples only, triggering VACUUM (INDEX_CLEANUP FALSE)? > Agreed. To invoke autovacuum even on insert-only tables we would need check the number of inserted tuples since last vacuum. I think we can keep track of the number of inserted tuples since last vacuum to the stats collector and add the threshold to invoke vacuum with INDEX_CLEANUP = false. If an autovacuum worker confirms that the number of inserted tuples exceeds the threshold it invokes vacuum with INDEX_CLEANUP = false. However if the number of dead tuples also exceeds the autovacuum thresholds (autovacuum_vacuum_threshold and autovacuum_vacuum_scale_factor) it should invoke vacuum with INDEX_CLEANUP = true. Therefore new threshold makes sense only when it's lower than the autovacuum thresholds. I guess we can have one new GUC parameter to control scale factor. Since only relatively large tables will require this feature we might not need the threshold based the number of tuples. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
Commits
-
Further improve stability fix for partition_aggregate test.
- 18d85e9b8a2b 13.0 landed
-
Improve stability fix for partition_aggregate test.
- 7cb0a423f914 13.0 landed
-
Attempt to stabilize partitionwise_aggregate test
- cefb82d49e21 13.0 landed
-
Fix race condition in statext_store().
- fe3036527a1f 13.0 landed
- 6c426cd43790 12.3 landed
-
Attempt to fix unstable regression tests, take 2
- 24566b359d09 13.0 landed
-
Attempt to fix unstable regression tests
- 2dc16efedc76 13.0 landed
-
Trigger autovacuum based on number of INSERTs
- b07642dbcd8d 13.0 landed
-
Fix upper limit for vacuum_cleanup_index_scale_factor
- 4d54543efa5e 11.0 cited