On Tue, Jul 11, 2006 at 10:02:49AM -0400, Tom Lane wrote:
Currently, we restrict btree index tuples to a size that ensures three of
them will fit on a page. The motivation for this is the following two
considerations:
1. In a non-rightmost page, we need to include a high key, or page
Jim C. Nasby [EMAIL PROTECTED] 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
On Wed, Jul 19, 2006 at 06:23:44PM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] 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
Jim C. Nasby [EMAIL PROTECTED] writes:
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.
No, because (a) that confuses the first key that
Currently, we restrict btree index tuples to a size that ensures three of
them will fit on a page. The motivation for this is the following two
considerations:
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.
2. In a
Tom,
Obviously a tree containing many such pages would be awfully inefficient
to search, but I think a more common case is that there are a few wide
entries in an index of mostly short entries, and so pushing the hard
limit up a little would add some flexibility with little performance
cost in
Ühel kenal päeval, T, 2006-07-11 kell 10:46, kirjutas Josh Berkus:
Tom,
Obviously a tree containing many such pages would be awfully inefficient
to search, but I think a more common case is that there are a few wide
entries in an index of mostly short entries, and so pushing the hard
