From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robin Iddon <robin(at)edesix(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: 8.0.3 pg_autovacuum doesn't clear out stats table? |
Date: | 2006-02-23 21:39:24 |
Message-ID: | 26139.1140730764@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Robin Iddon <robin(at)edesix(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Fuhr | 2006-02-23 21:40:25 | Re: how to use PostGIS with Postgres |
Previous Message | Jim C. Nasby | 2006-02-23 21:23:37 | Re: PGPASSWORD |