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 <p...@bowt.ie>: > On Sun, Sep 17, 2017 at 2:52 PM, Neto pr <neto...@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 >
