From: | "Florian Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
Cc: | "Pgsql-General" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Strange VACUUM behaviour |
Date: | 2005-11-29 14:26:02 |
Message-ID: | 1439.62.178.187.39.1133274362.squirrel@mail.office.solution-x.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, November 29, 2005 0:37, Jim C. Nasby said:
> One issue is that pg_toast tables can't vacuum rows until their
> respective rows have been deleted by vacuuming the base table. But it's
> still odd that the count decreases by 4 each time you run it.
So, VACUUM <big-table> would first vacuum <big-table>, then
pg_toast_<big-table-oid>, and finally pg_toast_<big-table-oid>_index?
> As for the length of time, that could be due to heavily loaded hardware.
> You might do better if you increase vacuum_memory (or whatever the
> setting was called in 7.4...)
Well, the hardware is a few years old, and vacuum runs used to "take
their time" - but always in the range of a few hours, never a few days.
vacuum_mem is already set to 256MB.
The CPU-Load was quite high though (The VACUUM process continously used
about 30% CPU) - Which is strange, since VACUUM is supposed to be CPU-bound,
isn't it?
> That index does have about 20% bloat though; so a reindex would probably
> be a good idea.
Will it help if I REINDEX the <big-table>? Will the automatically
REINDEX the toast-indices too?
BTW - Where do I find information about the internal workings of
TOAST-Tables? I learned during this problem that I don't really
know how these things work.
greetings, Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Sterpu Victor | 2005-11-29 16:00:32 | sequence problem - many rows |
Previous Message | R, Rajesh (STSD) | 2005-11-29 14:20:39 | Error in IPV6 client authenciation |