Tom Lane wrote:
Dylan Hansen <[EMAIL PROTECTED]> 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
