Re: Berserk Autovacuum (let's save next Mandrill)
Laurenz Albe <laurenz.albe@cybertec.at>
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Darafei "Komяpa" Praliaskouski <me@komzpa.net>
Cc: David Rowley <dgrowleyml@gmail.com>, Masahiko Sawada
<masahiko.sawada@2ndquadrant.com>, Justin Pryzby <pryzby@telsasoft.com>,
Tomas Vondra <tomas.vondra@2ndquadrant.com>, Amit Kapila
<amit.kapila16@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, 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-13T12:04:16Z
Lists: pgsql-hackers
On Fri, 2020-03-13 at 12:05 +0300, Darafei "Komяpa" Praliaskouski wrote: > 1. introduce no new parameters and trigger autovacuum if the number > > of inserts exceeds the regular vacuum threshold. > > > > 2. introduce the new parameters with high base threshold and zero scale factor. > > Both of these look good to me. 1 is approach in my initial patch > sketch, 2 is approach taken by Laurenz. > Values I think in when considering vacuum is "how many megabytes of > table aren't frozen/visible" (since that's what translates into > processing time knowing io limits of storage), and "how many pages > aren't yet vacuumed". > > Threshold in Laurenz's patch was good enough for my taste - it's > basically "vacuum after every gigabyte", and that's exactly what we > implemented when working around this issue manually. There's enough > chance that latest gigabyte is in RAM and vacuum will be super fast on > it; reading a gigabyte of data is not a showstopper for most > contemporary physical and cloud environments I can think of. If > reading a gigabyte is a problem already then wraparound is a > guaranteed disaster. > > About index only scan, this threshold seems good enough too. There's a > good chance last gig is already in RAM, and previous data was > processed with previous vacuum. Anyway - with this patch Index Only > Scan starts actually working :) > > I'd vote for 2 with a note "rip it off all together later and redesign > scale factors and thresholds system to something more easily > graspable". Whoever needs to cancel the new behavior for some reason > will have a knob then, and patch is laid out already. > > > 3. introduce the new parameters with low base threshold and high scale factor. > > This looks bad to me. "the bigger the table, the longer we wait" does > not look good for me for something designed as a measure preventing > issues with big tables. Thanks for the feedback. It looks like we have a loose consensus on #2, i.e. my patch. Yours, Laurenz Albe
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