Re: auto-vacuum & Negative "anl" Values
От | Dylan Hansen |
---|---|
Тема | Re: auto-vacuum & Negative "anl" Values |
Дата | |
Msg-id | E6764273-3A5B-4DA3-8B00-036FCAA74B78@pixpo.com обсуждение исходный текст |
Ответ на | Re: auto-vacuum & Negative "anl" Values ("Matthew T. O'Connor" <matthew@zeut.net>) |
Ответы |
Re: auto-vacuum & Negative "anl" Values
|
Список | pgsql-general |
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@pixpo.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. Thecalculation in question isanltuples = tabentry->n_live_tuples + tabentry->n_dead_tuples -tabentry->last_anl_tuples;Apparently somehow last_anl_tuples has managed to get to be bigger thann_live_tuples, which maybe could happen after a delete. Should we beclamping 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 tochoose an index scan if your joining column's datatypes do notmatch
В списке pgsql-general по дате отправления: