Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Claudio Freire <klaussfreire@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>,
PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Date: 2018-03-29T17:09:48Z
Lists: pgsql-hackers
Claudio Freire <klaussfreire@gmail.com> writes: > On Wed, Mar 28, 2018 at 6:54 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> After 0001, >> there's no reason to assume that vacuum is particularly likely to get >> cancelled between having made cleanups and having updated the upper FSM >> levels. (Maybe the odds are a bit more for the no-indexes case, but >> that doesn't seem like it's common enough to justify a special mechanism >> either.) > Why not? > Any kind of DDL (even those that don't rewrite the heap) would cancel > autovacuum. > You might think DDL isn't common enough to worry about, but I've seen > cases where regular reindex were required to keep index bloat in check > (and were cron'd), and those cancel autovacuum all the time. If you've got a situation where every vacuum gets canceled partway through, you've got bloat problems regardless, because the heap tuples are never getting removed in the first place; worrying about whether the FSM is up to date is pretty pointless. The 0001 patch basically updates the FSM as soon as it can after the tuples are actually deleted, so I think we've made the window as small as practical, and I don't really see a need to do extra work (and add substantial extra complexity) to deal with missed cleanup a bit sooner. People who are dealing with this sort of scenario a lot might be well advised to reduce autovacuum's maintenance_work_mem, so that the cleanup cycles happen more often. That's kind of costly in terms of the number of index scans, but it reduces the amount of cleanup work that can be lost to a cancel. (I'd also argue that a setup such as you describe is very possibly making things worse not better. Perhaps the 0001 patch will go some way towards making it less necessary to do that.) I've pushed 0001 and a replacement for 0003. I have to go do something else right now, but I'll take a closer look at 0004 later. regards, tom lane
Commits
-
Do index FSM vacuuming sooner.
- c79f6df75dd3 11.0 landed
-
Remove UpdateFreeSpaceMap(), use FreeSpaceMapVacuumRange() instead.
- a063baaced27 11.0 landed
-
While vacuuming a large table, update upper-level FSM data every so often.
- 851a26e26637 11.0 landed
-
Simplify autovacuum work-item implementation
- 31ae1638ce35 11.0 cited