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
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 |