Re: auto-vacuum & Negative "anl" Values

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: auto-vacuum & Negative "anl" Values
Дата
Msg-id 6746.1151008533@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: auto-vacuum & Negative "anl" Values  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-general
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> Apparently somehow last_anl_tuples has managed to get to be bigger than
>> n_live_tuples, which maybe could happen after a delete.  Should we be
>> clamping last_anl_tuples to not exceed n_live_tuples somewhere?
>> Alvaro and Matthew, what do you think?

> Hmm ... I'd think that the number of dead tuples plus live tuples should
> never be smaller than the number of tuples seen at last analyze.

The scenario I was imagining was big delete followed by
VACUUM-without-ANALYZE.  In this situation, it looks to me like
pgstat_recv_vacuum updates n_live_tuples to the new smaller value
and doesn't do anything to last_anl_tuples.  I'm thinking we need

    tabentry->n_live_tuples = msg->m_tuples;
    tabentry->n_dead_tuples = 0;
    if (msg->m_analyze)
    {
        tabentry->last_anl_tuples = msg->m_tuples;
        if (msg->m_autovacuum)
            tabentry->autovac_analyze_timestamp = msg->m_vacuumtime;
        else
            tabentry->analyze_timestamp = msg->m_vacuumtime;
    }
+    else
+    {
+        /* last_anl_tuples must never exceed n_live_tuples */
+        tabentry->last_anl_tuples = Min(tabentry->last_anl_tuples,
+                        msg->m_tuples);
+    }
}

but perhaps I'm confused.

            regards, tom lane

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

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: aggregate of bitstrings
Следующее
От: Dylan Hansen
Дата:
Сообщение: Re: auto-vacuum & Negative "anl" Values