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

From Tom Lane
Subject Re: [HACKERS] The number of bytes is stored in index_size of pgstatindex() ?
Date
Msg-id 15135.1455843233@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] The number of bytes is stored in index_size of pgstatindex() ?  (Peter Geoghegan <pg@heroku.com>)
Responses Re: [HACKERS] The number of bytes is stored in index_size of pgstatindex() ?  (Peter Geoghegan <pg@heroku.com>)
List pgsql-docs
Peter Geoghegan <pg@heroku.com> writes:
> On Thu, Feb 18, 2016 at 4:15 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Because they've been removed from the right-link/left-link chains.

> That isn't the same thing as being inaccessible by scans, clearly
> (just what you call the "leaf scan sequence").

Only a physical-order scan, ie vacuum, would visit a dead page
(ignoring transient corner cases like a page getting deleted while an
indexscan is in flight to it).  So I think treating it as part of the
fragmentation measure is completely wrong: the point of that measure,
AFAICS, is to model how close an index-order traversal is to linear.
Half-dead pages are also normally very transient --- the only way they
persist is if there's a crash partway through a page deletion.  So I think
it's appropriate to assume that future indexscans won't visit those,
either.

> there are usage patterns where half-dead pages might accumulate.

Other than a usage pattern of "randomly SIGKILL backends every few
seconds", I don't see how that would happen.

            regards, tom lane


pgsql-docs by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] The number of bytes is stored in index_size of pgstatindex() ?
Next
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] The number of bytes is stored in index_size of pgstatindex() ?