public inbox for [email protected]  

help / color / mirror / Atom feed

From: Neto pr <[email protected]>
To: Peter Geoghegan <[email protected]>
Cc: postgres performance list <[email protected]>
Subject: Re: Pageinspect bt_metap help
Date: Mon, 18 Sep 2017 11:31:47 -0300
Message-ID: <CA+wPC0NbHJ=awqjkq-GzosQ1r=nGN=2=zk6x=7btVCk7=4SABg@mail.gmail.com> (raw)
In-Reply-To: <CAH2-Wzka8Xkb79T5TbTeHPch2dTpWY+HsViqNLtKSKXY9bzOFA@mail.gmail.com>
References: <CA+wPC0MRuc0qn6v57VNtBE0Dh-r1Bcugi4FHHqC_kY-1X2tzGQ@mail.gmail.com>
	<CAH2-Wzka8Xkb79T5TbTeHPch2dTpWY+HsViqNLtKSKXY9bzOFA@mail.gmail.com>
List-Unsubscribe:  <mailto:[email protected]?body=unsub%20pgsql-performance>

Very interesting information.
See if I'm right, so for performance purposes, would it be better to
consider the columns: fast_root and fast_level instead of the root and
level columns?

I have read that even deleting records the B-tree tree is not rebuilt, so
it does not cause overhead in dbms, and can have null pointers.

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.

Best Regards
Neto

2017-09-17 18:59 GMT-03:00 Peter Geoghegan <[email protected]>:

> On Sun, Sep 17, 2017 at 2:52 PM, Neto pr <[email protected]> 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
>

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Pageinspect bt_metap help
  In-Reply-To: <CA+wPC0NbHJ=awqjkq-GzosQ1r=nGN=2=zk6x=7btVCk7=4SABg@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox