Re: Pageinspect bt_metap help

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Neto pr <netopr9(at)gmail(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Pageinspect bt_metap help
Date: 2017-09-19 03:28:19
Message-ID: 3949.1505791699@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> On Mon, Sep 18, 2017 at 7:31 AM, Neto pr <netopr9(at)gmail(dot)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.

My (vague) recollection is that it's actually useful in cases where the
live key-space constantly migrates to the right, so that the original
upper-level key splits would become impossibly unbalanced. This isn't
all that unusual a situation; consider timestamp keys for instance,
in a table where old data gets flushed regularly.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Jonathan Rogers 2017-09-19 03:30:59 Re: https://stackoverflow.com/questions/28844170/how-to-limit-the-memory-that-is-available-for-postgressql-server
Previous Message George Neuner 2017-09-19 02:44:56 Re: https://stackoverflow.com/questions/28844170/how-to-limit-the-memory-that-is-available-for-postgressql-server