Thread: Re: My quick and dirty "solution" (Re: Performance P roblem with Vacuum of bytea table (PG 8.0.13))
Re: My quick and dirty "solution" (Re: Performance P roblem with Vacuum of bytea table (PG 8.0.13))
From
"Andreas Kostyrka"
Date:
TOASTed means storage outside of the main table. But AFAIK, only rows bigger 2K are considered for toasting. Andreas -- Ursprüngl. Mitteil. -- Betreff: Re: My quick and dirty "solution" (Re: [PERFORM] Performance Problem with Vacuum of bytea table (PG 8.0.13)) Von: Bastian Voigt <post@bastian-voigt.de> Datum: 25.05.2007 14:13 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