Re: [HACKERS] The number of bytes is stored in index_size of pgstatindex() ?
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] The number of bytes is stored in index_size of pgstatindex() ? |
Дата | |
Msg-id | 15135.1455843233@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] The number of bytes is stored in index_size of pgstatindex() ? (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: [HACKERS] The number of bytes is stored in index_size of
pgstatindex() ?
|
Список | 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 по дате отправления: