From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Dylan Hansen <dhansen(at)pixpo(dot)com>, pgsql-general(at)postgresql(dot)org, "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net> |
Subject: | Re: auto-vacuum & Negative "anl" Values |
Date: | 2006-06-22 20:35:33 |
Message-ID: | 6746.1151008533@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Alvaro Herrera <alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dylan Hansen | 2006-06-22 20:42:39 | Re: auto-vacuum & Negative "anl" Values |
Previous Message | Joe Conway | 2006-06-22 20:30:15 | Re: aggregate of bitstrings |