Richard Huxton wrote:
Could you check the output of vacuum verbose on that table and see how
much work it's doing? I'd have thought the actual bytea data would be
TOASTed away to a separate table for storage, leaving the vacuum with
very little work to do.
I'm quite new to postgres (actually I just ported our running
application from MySQL...), so I don't know what toast means. But I
noticed that vacuum also tried to cleanup some "toast" relations or so.
This was what took so long.
It might well be your actual problem is your disk I/O is constantly
saturated and the vacuum just pushes it over the edge. In which case
you'll either need more/better disks or to find a quiet time once a
day to vacuum and just do so then.
Yes, that was definitely the case. But now everything runs smoothly
again, so I don't think I need to buy new disks.
Regards
Bastian
--
Bastian Voigt
Neumünstersche Straße 4
20251 Hamburg
telefon +49 - 40 - 67957171
mobil +49 - 179 - 4826359
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
