Re: My quick and dirty "solution" (Re: Performance P roblem with Vacuum of bytea table (PG 8.0.13)) - Mailing list pgsql-performance

From Andreas Kostyrka
Subject Re: My quick and dirty "solution" (Re: Performance P roblem with Vacuum of bytea table (PG 8.0.13))
Date
Msg-id GXZ5fwSlygqn.B27xCW1Q@heaven.kostyrka.org
Whole thread Raw
List pgsql-performance
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


pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: general PG network slowness (possible cure) (repost)
Next
From: Richard Huxton
Date:
Subject: Re: LIKE search and performance