Peter Geoghegan <pg@xxxxxxx> writes: > On Mon, Sep 18, 2017 at 7:31 AM, Neto pr <netopr9@xxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
