On Tue, Dec 30, 2014 at 12:21 PM, Heikki Linnakangas <hlinnakan...@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 00 00 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers