MIME-Version: 1.0
In-Reply-To: 
 <CA+wPC0NbHJ=awqjkq-GzosQ1r=nGN=2=zk6x=7btVCk7=4SABg@mail.gmail.com>
References: 
 <CA+wPC0MRuc0qn6v57VNtBE0Dh-r1Bcugi4FHHqC_kY-1X2tzGQ@mail.gmail.com>
 <CAH2-Wzka8Xkb79T5TbTeHPch2dTpWY+HsViqNLtKSKXY9bzOFA@mail.gmail.com>
 <CA+wPC0NbHJ=awqjkq-GzosQ1r=nGN=2=zk6x=7btVCk7=4SABg@mail.gmail.com>
From: Peter Geoghegan <pg@bowt.ie>
Date: Mon, 18 Sep 2017 18:07:26 -0700
Message-ID: 
 <CAH2-WzmvNvC4FGmixpMAFcq3GiPxMiZqw9-_4Gn_J34rAxg1NQ@mail.gmail.com>
Subject: Re: Pageinspect bt_metap help
To: Neto pr <netopr9@gmail.com>
Cc: postgres performance list <pgsql-performance@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On Mon, Sep 18, 2017 at 7:31 AM, Neto pr <netopr9@gmail.com> wrote:
> In my example, the values of fast_root, fast_root are equal to root, level,
> I believe that due to the newly created index and no delete operations
> occurred in the table.

Fast root and true root will probably never be different, even when
there are many deletions, including page deletions by VACUUM. As I
understand it, the fast root thing is for a fairly rare, though still
important edge case. It's a way of working around the fact that a
B-Tree can never become shorter due to the locking protocols not
allowing it. We can instead just pretend that it's shorter, knowing
that upper levels don't contain useful information.


-- 
Peter Geoghegan


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance