From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Documentation of bt_page_items()'s ctid field |
Date: | 2014-12-30 16:59:17 |
Message-ID: | 54A2D9E5.2030304@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/30/2014 04:08 AM, Peter Geoghegan wrote:
> Attached documentation patch describes the purpose of
> bt_page_items()'s ctid field. This has come up enough times in
> disaster recovery or testing scenarios that I feel it's worth drawing
> particular attention to.
How much detail on the b-tree internals do we want to put in the
pageinspect documentation? I can see that being useful, but should we
also explain e.g. that the first item on each (non-rightmost) page is
the high key?
> + Note that <structfield>ctid</> addresses a heap tuple if the
> + page under consideration is a B-Tree leaf page. Otherwise, for
> + internal B-Tree pages <structfield>ctid</> addresses a page in
> + the B-Tree itself (excluding the root page if and only if there
> + has not yet been a root page split, as in the example above).
> + These internally referenced pages are child pages, and may
> + themselves be leaf pages or internal pages.
I had a hard time understanding the remark about the root page. But in
any case, if you look at the flags set e.g. with bt_page_stats(), the
root page is flagged as also being a leaf page, when it is the only page
in the index. So the root page is considered also a leaf page in that case.
I'd suggest saying the same thing (or more) with fewer words:
In a B-tree leaf page, <structfield>ctid</> points to a heap tuple. In
an internal page, it points to another page in the index itself, and the
offset number part (the second number) of the ctid field is ignored.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2014-12-30 17:24:18 | Re: BUG #12330: ACID is broken for unique constraints |
Previous Message | Jeff Janes | 2014-12-30 16:53:43 | Re: 9.5: Better memory accounting, towards memory-bounded HashAgg |