Re: Max size of a btree index entry - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: Max size of a btree index entry
Date
Msg-id 20060719232754.GF83250@pervasive.com
Whole thread Raw
In response to Re: Max size of a btree index entry  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Max size of a btree index entry  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Jul 19, 2006 at 06:23:44PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <jnasby@pervasive.com> writes:
> > On Tue, Jul 11, 2006 at 10:02:49AM -0400, Tom Lane wrote:
> >> 1. In a non-rightmost page, we need to include a "high key", or page
> >> boundary key, that isn't one of the useful data keys.
>  
> > Why does a leaf page need a boundary key?
> 
> So you can tell whether a proposed insertion ought to go into this page,
> or the one to its right.  The tree descent logic doesn't guarantee that
> you descend to exactly the correct page --- if concurrent page splits
> are going on, you might have to "move right" one or more times after
> reaching the leaf level.  You need the boundary key to make this test
> correctly.
> 
> And of course, the reason there's no high key on the rightmost page is
> exactly that it has no right-hand neighbor, hence no upper limit on its
> delegated key space.

Could you not just scan right and see what the first key was? Thought
granted, that means there's a chance of a wasted page scan, but I think
that'd be somewhat of a corner case, so it might not be bad.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Freezing tuples on pages dirtied by vacuum
Next
From: "Jim C. Nasby"
Date:
Subject: Re: How does the planner deal with multiple possible indexes?