Re: New vacuum option to do only freezing

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New vacuum option to do only freezing
Date: 2019-02-27 17:45:47
Message-ID: 631670BB-CE95-40B5-9550-3C10417862FA@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2/27/19, 2:08 AM, "Masahiko Sawada" <sawada(dot)mshk(at)gmail(dot)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.

Nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2019-02-27 18:06:53 Re: query logging of prepared statements
Previous Message Robert Haas 2019-02-27 17:44:23 Re: [HACKERS] Block level parallel vacuum