Re: [DOCS] The number of bytes is stored in index_size of pgstatindex() ? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [DOCS] The number of bytes is stored in index_size of pgstatindex() ?
Date
Msg-id 10683.1455836792@sss.pgh.pa.us
Whole thread Raw
In response to Re: [DOCS] The number of bytes is stored in index_size of pgstatindex() ?  (Peter Geoghegan <pg@heroku.com>)
Responses Re: [DOCS] The number of bytes is stored in index_size of pgstatindex() ?  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
Peter Geoghegan <pg@heroku.com> writes:
> I think that the P_ISLEAF() instrumentation of free space and
> fragments might still need to happen for deleted and/or half dead
> pages.

Don't see why; the documentation and field names clearly imply that those
numbers are accumulated only over leaf pages.  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.)

> 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,
and rearranged them so that the most common case would be tested first.
I'm quite sure I didn't intend to change the statistical behavior, else
I would have updated docs and/or mentioned it in the commit message.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [DOCS] The number of bytes is stored in index_size of pgstatindex() ?
Next
From: Bruce Momjian
Date:
Subject: Re: New pg_upgrade data directory inside old one?