Re: Berserk Autovacuum (let's save next Mandrill)
Justin Pryzby <pryzby@telsasoft.com>
From: Justin Pryzby <pryzby@telsasoft.com>
To: Andres Freund <andres@anarazel.de>
Cc: David Rowley <dgrowleyml@gmail.com>, Laurenz Albe <laurenz.albe@cybertec.at>, 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>, pgsql-hackers@lists.postgresql.org, Alvaro Herrera <alvherre@2ndquadrant.com>, Michael Banck <mbanck@gmx.net>
Date: 2020-03-19T06:06:58Z
Lists: pgsql-hackers
On Fri, Mar 13, 2020 at 02:38:51PM -0700, Andres Freund wrote:
> On 2020-03-13 13:44:42 -0500, Justin Pryzby wrote:
> > Having now played with the patch, I'll suggest that 10000000 is too high a
> > threshold. If autovacuum runs without FREEZE, I don't see why it couldn't be
> > much lower (100000?) or use (0.2 * n_ins + 50) like the other autovacuum GUC.
>
> ISTM that the danger of regressing workloads due to suddenly repeatedly
> scanning huge indexes that previously were never / rarely scanned is
> significant (if there's a few dead tuples, otherwise most indexes will
> be able to skip the scan since the vacuum_cleanup_index_scale_factor
> introduction)).
We could try to avoid that issue here:
| /* If any tuples need to be deleted, perform final vacuum cycle */
| /* XXX put a threshold on min number of tuples here? */
| if (dead_tuples->num_tuples > 0)
| {
| /* Work on all the indexes, and then the heap */
| lazy_vacuum_all_indexes(onerel, Irel, indstats, vacrelstats,
| lps, nindexes);
|
| /* Remove tuples from heap */
| lazy_vacuum_heap(onerel, vacrelstats);
| }
As you said, an insert-only table can skip scanning indexes, but an
insert-mostly table currently cannot.
Maybe we could skip the final index scan if we hit the autovacuum insert
threshold?
I still don't like mixing the thresholds with the behavior they imply, but
maybe what's needed is better docs describing all of vacuum's roles and its
procedure and priority in executing them.
The dead tuples would just be cleaned up during a future vacuum, right ? So
that would be less efficient, but (no surprise) there's a balance to strike and
that can be tuned. I think that wouldn't be an issue for most people; the
worst case would be if you set high maint_work_mem, and low insert threshold,
and you got increased bloat. But faster vacuum if we avoided idx scans.
That might allow more flexibility in our discussion around default values for
thresholds for insert-triggered vacuum.
--
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