Re: Berserk Autovacuum (let's save next Mandrill)
Darafei Komяpa Praliaskouski <me@komzpa.net>
From: Darafei "Komяpa" Praliaskouski <me@komzpa.net>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2019-03-31T10:30:12Z
Lists: pgsql-hackers
> > If it's months, we probably want limit vacuum to working at a pretty > slow rate, say 1% of the table size per hour or something. If it's in > hours, we need to be a lot more aggressive. Right now we have no > information to tell us which of those things is the case, so we'd just > be shooting in the dark. Thing is, you don't need to spread out your vacuum in time if the rate of vacuuming matches rate of table growth. Can we mark tuples/pages as all-visible and all-frozen say, the moment they're pushed out of shared_buffers? -- Darafei Praliaskouski Support me: http://patreon.com/komzpa
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