Re: [WIP] [B-Tree] Keep indexes sorted by heap physical location

From: Kevin Grittner <kgrittn(at)gmail(dot)com>
To: Claudio Freire <klaussfreire(at)gmail(dot)com>
Cc: Peter Geoghegan <pg(at)heroku(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [WIP] [B-Tree] Keep indexes sorted by heap physical location
Date: 2016-08-19 14:00:15
Message-ID: CACjxUsN5fV0kV=YirXwA0S7LqoOJuy7soPtipDhUCemhgwoVFg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 18, 2016 at 5:04 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:

> But the choice of split point may make a difference for future
> insertions, so I'll look into that.

A database product I worked on a long time ago had an interesting
optimization for indexes that had multiple insertion points, each
of which was increasing. (Picture, for example 100 case types,
with case numbers inserted in sequence within each case type -- so
the first three felony cases would be CF000001, CF000002, and
CF000003; while the first three small claims cases would be
SC000001, SC000002, and SC000003.) That's not a terribly rare
usage pattern, in my experience. An index on such data is most
efficient if you split at the point of the index tuple being
inserted -- making it the last tuple on the left-hand page. I
don't know whether we might want to consider making that an option
somehow -- it just came to mind because of this discussion.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2016-08-19 14:08:25 Re: Why we lost Uber as a user
Previous Message Adrien Nayrat 2016-08-19 13:47:56 Re: LSN as a recovery target