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
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 |