Re: auto-vacuum & Negative "anl" Values

[Dylan Hansen <dhansen(at)pixpo(dot)com>]

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