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
