Re: [HACKERS] GUC for cleanup indexes threshold.
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2018-01-06T22:20:28Z
Lists: pgsql-hackers
Greetings, (pruned the CC list) * Michael Paquier (michael.paquier@gmail.com) wrote: > On Thu, Nov 30, 2017 at 12:06 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Wed, Nov 29, 2017 at 11:05 PM, Simon Riggs <simon@2ndquadrant.com> wrote: > >> Unless there is disagreement on the above, it seems we should apply > >> Yura's patch (an edited version, perhaps). > >> > > > > IIRC the patches that makes the cleanup scan skip has a problem > > pointed by Peter[1], that is that we stash an XID when a btree page is > > deleted, which is used to determine when it's finally safe to recycle > > the page. Yura's patch doesn't have that problem? > > > > [1] https://www.postgresql.org/message-id/CAH2-Wz%3D1%3Dt5fcGGfarQGcAWBqaCh%2BdLMjpYCYHpEyzK8Qg6OrQ%40mail.gmail.com > > The latest patch present on this thread does not apply > (https://www.postgresql.org/message-id/c4a47caef28024ab7528946bed264058@postgrespro.ru). > Please send a rebase. For now I am moving the patch to next CF, with > "waiting on author". We are now just about a week into the CF and this patch hasn't been updated and is still in 'waiting on author' state and it sounds like it might have a pretty serious issue based on the above comment. Masahiko Sawada, if this patch isn't viable or requires serious rework to be acceptable, then perhaps we should change its status to 'returned with feedback' and you can post a new patch for the next commitfest..? Otherwise, I'd encourage you to try and find time to post an updated patch soon, so that it can be reviewed. Thanks! Stephen
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