Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id C43C29FC1A9 for ; Fri, 25 May 2007 11:11:51 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 04109-04 for ; Fri, 25 May 2007 11:11:41 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from wp045.webpack.hosteurope.de (wp045.webpack.hosteurope.de [80.237.132.52]) by postgresql.org (Postfix) with ESMTP id A75219FC126 for ; Fri, 25 May 2007 11:11:47 -0300 (ADT) Received: from d088150.adsl.hansenet.de ([80.171.88.150] helo=[192.168.1.44]); authenticated by wp045.webpack.hosteurope.de running ExIM using esmtpa id 1HraW9-0002X8-Tc; Fri, 25 May 2007 16:11:45 +0200 Message-ID: <4656EEA1.8030409@bastian-voigt.de> Date: Fri, 25 May 2007 16:11:45 +0200 From: Bastian Voigt User-Agent: Thunderbird 2.0.0.0 (X11/20070502) MIME-Version: 1.0 To: Richard Huxton CC: pgsql-performance@postgresql.org Subject: Re: My quick and dirty "solution" (Re: Performance Problem with Vacuum of bytea table (PG 8.0.13)) References: <46569E6A.2060509@bastian-voigt.de> <4656BB5E.3000109@archonet.com> <4656BEF1.4050609@bastian-voigt.de> <4656C1C7.3000003@archonet.com> <4656C411.8010509@bastian-voigt.de> <4656CDC2.6030106@archonet.com> <4656D6EC.5060506@bastian-voigt.de> <4656E1B5.3020300@archonet.com> In-Reply-To: <4656E1B5.3020300@archonet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-bounce-key: webpack.hosteurope.de; post@bastian-voigt.de; 1180102307; 8f59cfcf; X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.538 tagged_above=0 required=5 tests=AWL=0.002, BAYES_40=-0.185, RCVD_IN_NJABL_PROXY=0.721 X-Spam-Level: X-Archive-Number: 200705/509 X-Sequence-Number: 24899 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