Re: New vacuum option to do only freezing

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: New vacuum option to do only freezing
Дата
Msg-id 20190404.091743.76975665.horiguchi.kyotaro@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: New vacuum option to do only freezing  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: New vacuum option to do only freezing  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
Hello.

At Wed, 3 Apr 2019 11:55:00 -0400, Robert Haas <robertmhaas@gmail.com> wrote in
<CA+Tgmoas581jpJ0TPaA38OhjXHgbLy8z1fuuHH7CaNkrboZJeA@mail.gmail.com>
> On Wed, Apr 3, 2019 at 1:32 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > Attached the updated version patches including the
> > DISABLE_PAGE_SKIPPING part (0003).
> 
> I am confused about nleft_dead_tuples.  It looks like it gets
> incremented whenever we set tupgone = true, regardless of whether we
> are doing index cleanup.  But if we ARE doing index cleanup then the
> dead tuple will not be left.  And if we are not doing index vacuum
> then we still don't need this for anything, because tups_vacuumed is
> counting the same thing.  I may be confused.  But if I'm not, then I
> think this should just be ripped out, and we should only keep
> nleft_dead_itemids.

tups_vacuumed is including heap_page_prune()ed tuples, which
aren't counted as "tupgone".

> As far as VacOptTernaryValue, I think it would be safer to change this
> so that VACOPT_TERNARY_DEFAULT = 0.  That way palloc0 will fill in the
> value that people are likely to want by default, which makes it less
> likely that people will accidentally write future code that doesn't
> clean up indexes.

It's convincing. My compalint was enabled=0 and disabled=1 is
confusing so I'm fine with default=0, disabled=1, enabled=2.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center




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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Inadequate executor locking of indexes
Следующее
От: Raymond Martin
Дата:
Сообщение: RE: minimizing pg_stat_statements performance overhead