Re: GUC for cleanup indexes threshold.
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
Amit Kapila <amit.kapila16@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, "Ideriha,
Takeshi" <ideriha.takeshi@jp.fujitsu.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>,
Kuntal Ghosh <kuntalghosh.2007@gmail.com>
Date: 2017-03-03T19:49:36Z
Lists: pgsql-hackers
On Fri, Mar 3, 2017 at 11:37 AM, Peter Geoghegan <pg@bowt.ie> wrote: > Please verify my understanding of your thought process: We don't have > to freeze indexes at all, ever, so if we see index bloat as a separate > problem, we also see that there is no need to *link* index needs to > the need for freezing. XID burn rate is a very bad proxy for how > bloated an index may be. Besides, we already have a separate trigger > for the thing that *actually* matters to indexes (the vacuum threshold > stuff). Another thing I wonder about: It would be okay to use the number of unset freeze map bits as a reasonable proxy for how much bloat is in the index the first time we vacuum. But, don't we then set the freeze map bits, losing any record of having skipped indexes? What mechanism exists that allows back-pressure to actually *build up* over many vacuum anti-wraparound cycles, so that we slowly but surely get around to actually vacuuming indexes at some point? -- Peter Geoghegan
Commits
-
Fix upper limit for vacuum_cleanup_index_scale_factor
- 4d54543efa5e 11.0 landed
-
Increase upper limit for vacuum_cleanup_index_scale_factor
- 6ca33a885bf8 11.0 landed
-
Fixes for vacuum_cleanup_index_scale_factor GUC option
- 9a994e37e08d 11.0 landed
-
Skip full index scan during cleanup of B-tree indexes when possible
- 857f9c36cda5 11.0 landed