Re: New vacuum option to do only freezing
От | Masahiko Sawada |
---|---|
Тема | Re: New vacuum option to do only freezing |
Дата | |
Msg-id | CAD21AoCbjkOmB+JsoQn1fq7YDu=_y-j-KwYk8zG=3W=rPvE9kQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: New vacuum option to do only freezing ("Bossart, Nathan" <bossartn@amazon.com>) |
Ответы |
Re: New vacuum option to do only freezing
|
Список | pgsql-hackers |
On Thu, Feb 28, 2019 at 2:46 AM Bossart, Nathan <bossartn@amazon.com> wrote: > > On 2/27/19, 2:08 AM, "Masahiko Sawada" <sawada.mshk@gmail.com> wrote: > >> + if (skip_index_vacuum) > >> + appendStringInfo(&buf, ngettext("%.0f tuple is left as dead.\n", > >> + "%.0f tuples are left as dead.\n", > >> + nleft), > >> + nleft); > >> > >> I think we could emit this metric for all cases, not only when > >> DISABLE_INDEX_CLEANUP is used. > > > > I think that tups_vacuumed shows total number of vacuumed tuples and > > is already shown in the log message. The 'nleft' counts the total > > number of recorded dead tuple but not counts tuples are removed during > > HOT-pruning. Is this a valuable for users in non-DISABLE_INDEX_CLEANUP > > case? > > I think it is valuable. When DISABLE_INDEX_CLEANUP is not used or it > is used for a relation with no indexes, it makes it clear that no > tuples were left marked as dead. Also, it looks like all of the other > information here is provided regardless of the options used. IMO it > is good to list all of the stats so that users have the full picture > of what VACUUM did. > I see your point. That seems good to me. Attached the updated version patch. I've incorporated all review comments I got and have changed the number of tuples being reported as 'removed tuples'. With this option, tuples completely being removed is only tuples marked as unused during HOT-pruning, other dead tuples are left. So we count those tuples during HOT-pruning and reports it as removed tuples. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
Вложения
В списке pgsql-hackers по дате отправления: