Re: 8.0.3 pg_autovacuum doesn't clear out stats table?
От | Tom Lane |
---|---|
Тема | Re: 8.0.3 pg_autovacuum doesn't clear out stats table? |
Дата | |
Msg-id | 26139.1140730764@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: 8.0.3 pg_autovacuum doesn't clear out stats table? (Robin Iddon <robin@edesix.com>) |
Ответы |
Re: 8.0.3 pg_autovacuum doesn't clear out stats table?
|
Список | pgsql-admin |
Robin Iddon <robin@edesix.com> writes: > The tuples and thresholds for the pg_statistic table look like they > might be the reason it doesn't get vacuumed. The question is, why does > the reltuples on the stats table keep climbing until you do a vacuum > full, at which point they return to (near) zero? No matter what > threshold and scale I set, I am not going to get that table vacuumed > because it's delete/update rate are 0 (it's always inserted to I believe). Quite incorrect --- if that were so, there would be no dead tuples for vacuum to remove, hm? Actually ANALYZE does an update-or-insert-if-not-present fandango. I'm sort of mystified by your report. I can think of several ways that the system might fail to notice that pg_statistic needs vacuuming, but none of them seem to actually occur in the current code, and I don't see any relevant difference in the CVS logs (I admit to being too lazy to build an exact 8.0.3 version to test --- but 8.0.7 seems fine). Can you keep an eye on pg_statistic's entry in the pg_stat_all_tables view for each affected database, and confirm whether the n_tup_upd/ n_tup_del counts are rising over time or not? That would at least narrow down the problem a bit. regards, tom lane
В списке pgsql-admin по дате отправления: