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
