Re: auto-vacuum & Negative "anl" Values

So can I assume that this is a bug?

The only resolution I can see right now is to setup a cron job that
will perform an ANALYZE periodically, as the pg_autovacuum ANALYZE
threshold is never reached.

Any other suggestions? Thanks for the input!
--
Dylan Hansen
Enterprise Systems Developer

On 24-Jun-06, at 4:09 PM, Matthew T. O'Connor wrote:

> Tom Lane wrote:
>> Dylan Hansen <dhansen(at)pixpo(dot)com> writes:
>>
>>> I have been spending some time looking into how auto-vacuum is
>>> performing on one of our servers. After putting the PostgreSQL
>>> logs in debug I noticed that the threshold for ANALYZE was never
>>> being hit for a particular table because the calculated value
>>> becomes increasingly negative.
>>>
>>
>> Hmm, it shouldn't ever be negative at all, I would think. The
>> calculation in question is
>>
>> anltuples = tabentry->n_live_tuples + tabentry->n_dead_tuples -
>> tabentry->last_anl_tuples;
>>
>> 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?
>
> I think I had something in the contrib version that checked this.
> I always assumed it would be caused by a stats reset which was more
> common in earlier PGSQL releases since stats_reset_on_startup (or
> whatever the correct spelling of that is) was enabled by default.
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>
>