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

  1. Fix upper limit for vacuum_cleanup_index_scale_factor

  2. Increase upper limit for vacuum_cleanup_index_scale_factor

  3. Fixes for vacuum_cleanup_index_scale_factor GUC option

  4. Skip full index scan during cleanup of B-tree indexes when possible