Re: [GENERAL] ANALYZE getting dead tuple count hopelessly wrong

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [GENERAL] ANALYZE getting dead tuple count hopelessly wrong
Дата
Msg-id 28334.1206977563@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [GENERAL] ANALYZE getting dead tuple count hopelessly wrong  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
Ответы Re: [GENERAL] ANALYZE getting dead tuple count hopelessly wrong  ("Pavan Deolasee" <pavan.deolasee@gmail.com>)
Список pgsql-hackers
"Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
> Seems like the redirected-dead line pointers are playing spoil-sport here.
> In this particular example, the deleted tuples may get truncated to
> redirected-dead line pointers. Analyze would report them as empty
> slots and not as dead tuples. So in the worst case, if all the deleted
> tuples are already truncated to redirected-dead line pointers, analyze
> may report "zero" dead tuple count.

[ Please see if you can stop using the "redirected dead" terminology ]

Yeah, I think I agree.  The page pruning code is set up so that changing
a line pointer to DEAD state doesn't change the count of dead tuples in
the table, so we are counting unreclaimed DEAD pointers as still being
dead tuples requiring VACUUM.  ANALYZE should surely not affect that.

It looks like there's no trivial way to get ANALYZE to do things that
way, though.  heap_release_fetch() doesn't distinguish a DEAD line
pointer from an unused or redirected one.  But in the current
implementation of ANALYZE there's really no benefit to using
heap_release_fetch anyway --- it always examines all line pointers
on each selected page, so we might as well rewrite it to use a simple
loop more like vacuum uses.

I notice that this'd leave heap_release_fetch completely unused...
at least in HEAD I'd be tempted to get rid of it and restore heap_fetch
to its former simplicity.

            regards, tom lane

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: first time hacker ;) messing with prepared statements
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [PATCHES] Minimum selectivity estimate for LIKE 'prefix%'