On Thu, Feb 18, 2016 at 3:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Don't see why; the documentation and field names clearly imply that those
> numbers are accumulated only over leaf pages.
Then I guess what might be lacking is a delineation of what a leaf
page is for the purposes of pgstatindex().
> I certainly wouldn't expect
> the fragmentation measure to include dead pages, for example, since they
> would not get traversed by scans. (Whether the "rightlink points to a
> higher page number" rule for fragmentation is actually very useful is a
> separate question; but as long as that's the measure, only pages that
> are part of the leaf scan sequence should count.)
Why would dead pages not get traversed by scans? It's clear that they
would be traversed to the extent that there will be buffer locking and
inspection of the B-Tree special area flags to determine that the page
should be ignored.
>> Having looked at the 2008 commit d287818eb514d431 myself, ISTM
>> that your intent might well have been to have that happen -- why else
>> would any reasonable person have changed the order at all?
>
> My best guess is that I was thinking that the tests were independent
Dunno. I'd have thought that the basic fact that the ordering had some
significance was fairly obvious. One of the tests is "if
(P_IGNORE(...))", and I can't imagine that not provoking thought.
I'm particular about things like this because I care about making sure
these tools are useful for teaching novice hackers about Postgres
internals. I've made my point and will leave it at that, though.
--
Peter Geoghegan