Re: New vacuum option to do only freezing
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-11-08T13:29:34Z
Lists: pgsql-hackers
On 2018-Nov-08, Masahiko Sawada wrote: > On Tue, Nov 6, 2018 at 2:48 AM Robert Haas <robertmhaas@gmail.com> wrote: > > > > On Mon, Nov 5, 2018 at 3:12 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > Adding a field-and-value style option might be worth. Or maybe we can > > > add one option for example freeze_without_index_cleanup? > > > > That seems non-orthogonal. We have an existing flag to force freezing > > (FREEZE); we don't need a second option that does the same thing. > > Skipping the index scans (and thus necessarily the second heap pass) > > is a separate behavior which we don't currently have a way to control. > > We already have disable_page_skipping option, not (page_skipping > false). So ISMT disable_index_cleanup would be more natural. Also, > since what to do with this option is not only skipping vacuum indexes > but also skipping removeing dead tuples on heap, I think that the > option should have a more understandable name for users indicating > that both it removes dead tuples less than the normal vacuum and it's > aimed to freeze tuple more faster. Of course we document them, though. I would name this based on the fact that it freezes quickly -- something like FAST_FREEZE perhaps. The other things seem implementation details. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Add toast-level reloption for vacuum_index_cleanup
- ce59b75d449d 12.0 landed
-
heap_prepare_freeze_tuple: Simplify coding
- 2bf372a4ae26 12.0 landed
-
Fix missing word.
- 6665305e17ed 12.0 landed
-
Allow VACUUM to be run with index cleanup disabled.
- a96c41feec6b 12.0 landed
-
Don't mark pages all-visible spuriously
- d2599ecfcc74 11.0 cited