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 по дате отправления: