X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id B3B389DC881 for ; Mon, 16 Jan 2006 18:48:26 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 62124-06 for ; Mon, 16 Jan 2006 18:48:26 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.refusion.com (mail.refusion.com [213.144.155.20]) by postgresql.org (Postfix) with ESMTP id 82CF69DC886 for ; Mon, 16 Jan 2006 18:48:20 -0400 (AST) Received: from iwing by mail.refusion.com (MDaemon.PRO.v8.1.4.R) with ESMTP id md50000479366.msg for ; Mon, 16 Jan 2006 23:47:02 +0100 Message-ID: <070501c61aee$ed450560$6402a8c0@iwing> From: To: References: <43CC1938.7020807@gmail.com> <18875.1137451410@sss.pgh.pa.us> Subject: Re: new to postgres (and db management) and performance already a problem :-( Date: Mon, 16 Jan 2006 23:48:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 X-Authenticated-Sender: info@alternize.com X-Spam-Processed: mail.refusion.com, Mon, 16 Jan 2006 23:47:02 +0100 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 80.238.235.198 X-Return-Path: me@alternize.com X-MDaemon-Deliver-To: pgsql-performance@postgresql.org X-ClamAV: Pass X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=2.715 required=5 tests=[AWL=-0.708, DNS_FROM_RFC_DSN=2.872, NO_REAL_NAME=0.55, UNPARSEABLE_RELAY=0.001] X-Spam-Score: 2.715 X-Spam-Level: ** X-Archive-Number: 200601/212 X-Sequence-Number: 16690 > That does sound like a lack-of-vacuuming problem. If the performance > goes back where it was after VACUUM FULL, then you can be pretty sure > of it. Note that autovacuum is not designed to fix this for you: it > only ever issues regular vacuum not vacuum full. in our db system (for a website), i notice performance boosts after a vacuum full. but then, a VACUUM FULL takes 50min+ during which the db is not really accessible to web-users. is there another way to perform maintenance tasks AND leaving the db fully operable and accessible? thanks, thomas