MIME-Version: 1.0
In-Reply-To: 
 <CA+wPC0MRuc0qn6v57VNtBE0Dh-r1Bcugi4FHHqC_kY-1X2tzGQ@mail.gmail.com>
References: 
 <CA+wPC0MRuc0qn6v57VNtBE0Dh-r1Bcugi4FHHqC_kY-1X2tzGQ@mail.gmail.com>
From: Peter Geoghegan <pg@bowt.ie>
Date: Sun, 17 Sep 2017 14:59:34 -0700
Message-ID: 
 <CAH2-Wzka8Xkb79T5TbTeHPch2dTpWY+HsViqNLtKSKXY9bzOFA@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 Sun, Sep 17, 2017 at 2:52 PM, Neto pr <netopr9@gmail.com> wrote:
> I am using Postgresql extension pageinspect.
>
> Could someone tell me the meaning of these columns: magic, version, root,
> level, fastroot, fastlevel of the bt_metap function.
>
> This information is not presents in the documentation.

A magic number distinguishes the meta-page as a B-Tree meta-page. A
version number is used for each major incompatible revision of the
B-Tree code (these are very infrequent).

The fast root can differ from the true root following a deletion
pattern that leaves a "skinny index". The implementation can never
remove a level, essentially because it's optimized for concurrency,
though it can have a fast root, to just skip levels. This happens to
levels that no longer contain any distinguishing information in their
single internal page.

I imagine that in practice the large majority of B-Trees never have a
true root that differs from its fast root - you see this with repeated
large range deletions. Probably nothing to worry about.

> The height of the b-tree (position of node farthest from root to leaf), is
> the column Level?

Yes.

If you want to learn more about the B-Tree code, I suggest that you
start by looking at the code for contrib/amcheck.

-- 
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