Re: GUC for cleanup indexes threshold.
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
From: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
To: sawada.mshk@gmail.com
Cc: pg@bowt.ie, andres@anarazel.de, robertmhaas@gmail.com,
david@pgmasters.net,
amit.kapila16@gmail.com, simon@2ndquadrant.com,
ideriha.takeshi@jp.fujitsu.com, pgsql-hackers@postgresql.org,
kuntalghosh.2007@gmail.com
Date: 2017-09-25T11:37:59Z
Lists: pgsql-hackers
At Mon, 25 Sep 2017 19:20:07 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in <CAD21AoAzKJnc8UM728c0BMHx=7itJh4Db_Lj3Y31itnGrj-heQ@mail.gmail.com> > >> * we stash an XID when a btree page is deleted, which is used to > >> determine when it's finally safe to recycle the page > > > > Is it a "problem" of this proposal? > > > > As Peter explained before[1], the problem is that there is an XID > stored in dead btree pages that is used in the subsequent > RecentGlobalXmin interlock that determines if recycling is safe. > > [1] https://www.postgresql.org/message-id/CAH2-Wz%3D1%3Dt5fcGGfarQGcAWBqaCh%2BdLMjpYCYHpEyzK8Qg6OrQ%40mail.gmail.com Yeah I know that, and I understand that it is the reason why it is bad to just skip looking the GUC regardless. On the other hand looking the recycle status, I think we don't need the GUC. (I believe) The patch is *a Poc* in the way. (I'd like to let RecordPageWithFreeSpace to return the previous value to avoid duplicate fsm search..) regards, -- Kyotaro Horiguchi NTT Open Source Software Center
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