Re: Berserk Autovacuum (let's save next Mandrill)
Justin Pryzby <pryzby@telsasoft.com>
From: Justin Pryzby <pryzby@telsasoft.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, David Rowley <dgrowleyml@gmail.com>, Tomas Vondra <tomas.vondra@2ndquadrant.com>, Amit Kapila <amit.kapila16@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Darafei Komяpa Praliaskouski <me@komzpa.net>, Andres Freund <andres@anarazel.de>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>, Alvaro Herrera <alvherre@2ndquadrant.com>, Michael Banck <mbanck@gmx.net>
Date: 2020-03-16T21:07:57Z
Lists: pgsql-hackers
On Mon, Mar 16, 2020 at 08:49:43PM +0100, Laurenz Albe wrote: > On Mon, 2020-03-16 at 07:47 -0500, Justin Pryzby wrote: > > It seems to me that the easy thing to do is to implement this initially without > > FREEZE (which is controlled by vacuum_freeze_table_age), and defer until > > July/v14 further discussion and implementation of another GUC/relopt for > > autovacuum freezing to be controlled by insert thresholds (or ratio). > > Freezing tuples is the point of this patch. > As I have said, if you have a table where you insert many rows in few > transactions, you would trigger an autovacuum that then ends up doing nothing > because none of the rows have reached vacuum_freeze_table_age yet. > > Then some time later you will get a really large vacuum run. Best practice is to vacuum following bulk load. I don't think this patch is going to change that. Bulk-loaded tuples will be autovacuumed, which is nice, but I don't think it'll be ideal if large bulk loads trigger an autovacuum with cost delays which ISTM if it runs with FREEZE will take even longer. If it's a bulk load, then I think it's okay to assume it was vacuumed, or otherwise that it'll eventually be hit by autovac at some later date. If it's not a "bulk load" but a normal runtime, and the table continues to receive inserts/deletes, then eventually it'll hit a vacuum threshold and tuples can be frozen. If it receives a bunch of activity, which then stops (like a partition of a table of timeseries data), then maybe it doesn't hit a vacuum threshold, until wraparound vacuum. I think in that case it's not catastrophic, since then it wasn't big enough to hit any threshold (it's partitioned). If every day, autovacuum kicks in and does wraparound vacuum on table with data from (say) 100 days ago, I think that's reasonable. One case which would suck is if the insert_threshold were 1e6, and you restore a DB with 1000 tables of historic data (which are no longer being inserted into) which have 9e5 rows each (just below the threshold). Then autovacuum will hit them all at once. The solution to that is to manual vacuum after bulk load, same as today. As a practical matter, some of the tables are likely to hit the autovacuum insert threshold, and some are likely to be pruned (or updated) before wraparound vacuum, so the patch usually does improve that case. -- Justin
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