Re: Faster inserts with mostly-monotonically increasing values

From: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Tels <nospam-pg-abuse(at)bloodgate(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(dot)riggs(at)2ndquadrant(dot)com>
Subject: Re: Faster inserts with mostly-monotonically increasing values
Date: 2018-01-05 03:35:02
Message-ID: CABOikdOMiMMTqxMkhnECZRW7YApWeb3YpPsezM2qZ4dBAQ1yjQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 4, 2018 at 6:05 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
wrote:

> Pavan Deolasee wrote:
> > On Tue, Jan 2, 2018 at 7:15 PM, Tels <nospam-pg-abuse(at)bloodgate(dot)com>
> wrote:
> >
> > > Just a question trying to understand how btree indexes work:
> > >
> > > If one inserts ever-increasing value, is the tree a balanced tree with
> a
> > > minimum (or at least not-as-high) number of levels, or does it
> increase in
> > > height every insert and creates a "tall stack"?
> >
> > AFAIK all pages will be half-filled in this case. Imagine if one index
> page
> > can accommodate N entries, the page will be split when (N+1)th entry is
> > added. The left page will have half the entries and the right page will
> get
> > the remaining. The next split will happen when the right page is full
> i.e.
> > when another N/2 entries are added. Thus there will be a split at every
> N/2
> > inserts, creating an index with half filled pages.
>
> Not really -- quoth _bt_findsplitloc():
>
> * If the page is the rightmost page on its level, we instead try to
> arrange
> * to leave the left split page fillfactor% full. In this way, when we are
> * inserting successively increasing keys (consider sequences, timestamps,
> * etc) we will end up with a tree whose pages are about fillfactor% full,
> * instead of the 50% full result that we'd get without this special case.
>
>
Ah ok. Thanks for pointing that out. Makes a lot more sense.

Thanks,
Pavan

--
Pavan Deolasee http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message TipTop Labs 2018-01-05 03:36:22 Re: BUG #14999: pg_rewind corrupts control file global/pg_control
Previous Message Stephen Frost 2018-01-05 02:26:17 Re: GSoC 2018