On Tue, Dec 30, 2014 at 12:21 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> In practice, we never store any actual key value for the "minus infinity"
> key. I guess the code would ignore it if it was there, but it would make
> more sense to explain that the first data key on an internal page does not
> have a key value. If there is a value there, it's a sign that something's
> wrong.
Well, depends on what you're exact definition of a key is, I suppose.
Here is what I see for a B-Tree's root page (it's a few hundred KiBs
in size):
postgres=# select * from bt_page_items('ix_order_custid', 3);itemoffset | ctid | itemlen | nulls | vars |
data
------------+--------+---------+-------+------+------------------------- 1 | (1,1) | 8 | f | f |
2 | (2,1) | 16 | f | f | 65 02 00 00 00 00 00 00 3 | (4,1) | 16 | f | f | d2 04
0000 00 00 00 00 4 | (5,1) | 16 | f | f | 28 07 00 00 00 00 00 00 5 | (6,1) | 16 | f
| f | b9 09 00 00 00 00 00 00
*** SNIP ***
It's storing an index tuple, but not a key value itself. I guess that
the equivocating comments (that I pasted here before, that appear over
_bt_compare()) about what is stored made me use the term garbage, but
off hand I'm not aware of how that could actually happen either.
Perhaps it's an obsolete comment, and the "data" field will always be
empty for "minus infinity" items?
I'll leave the exact description of this state of the "data" field to you.
--
Peter Geoghegan