Re: Documentation of bt_page_items()'s ctid field - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Documentation of bt_page_items()'s ctid field
Date
Msg-id CAM3SWZSM59L6uJyA9WNrWHTbXa2xkMO7N-ZqwRL+_Rsdc1tPhw@mail.gmail.com
Whole thread Raw
In response to Re: Documentation of bt_page_items()'s ctid field  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: Documentation of bt_page_items()'s ctid field  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
On Mon, Mar 9, 2015 at 3:51 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> How do I know if I am looking at a non-rightmost page?

It has a right-link (that's the easiest way to tell). It will (as the
docpatch points out) also necessarily have a ""high key" item.  We
know that we have to move right if the high key doesn't bound the
value we expected to find on the page (our scankey item - what the
index scan is searching for). So the high key goes with having a
rightlink, and in general we detect that we're looking at a
non-rightmost page based on the presence of a right-link.

The confusing thing is that some pages have a high-key *and* a "minus
infinity" item. The latter has "data" that is undefined (cannot be
interpreted as a value of any type). It is still logically a "real"
item, that represents minus infinity for the purposes of binary
searches. But the high key is not a "real" item, even though its
"data" *is* a well-defined value of the underlying IndexTuple type or
types. Typically, the high key "data" matches the first non-highkey
"real" item on the next/right page...not including the "minus
infinity" item, if any.

Is that any clearer? Basically, high key items are relevant to all
non-rightmost pages on all levels. OTOH, "minus infinity" items are
only relevant to internal (non-leaf) pages (and a pre-first-split root
page is considered a leaf page for this purpose). Internal,
non-rightmost pages (internal pages are typically only a small
minority of the total) have both.
-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Rethinking the parameter access hooks for plpgsql's benefit
Next
From: Michael Paquier
Date:
Subject: Re: Object files generated by ecpg test suite not ignored on Windows