X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 7A12E9FCED6 for ; Mon, 28 Aug 2006 10:13:41 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 54752-06 for ; Mon, 28 Aug 2006 10:13:25 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.logix-tt.com (mail.logix-tt.com [212.211.145.186]) by postgresql.org (Postfix) with ESMTP id 169179FCECE for ; Mon, 28 Aug 2006 10:13:26 -0300 (ADT) Received: from kingfisher.intern.logix-tt.com (p549D1A06.dip0.t-ipconnect.de [84.157.26.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.logix-tt.com (Postfix) with ESMTP id CA9EE6597B for ; Mon, 28 Aug 2006 15:15:32 +0200 (CEST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by kingfisher.intern.logix-tt.com (Postfix) with ESMTP id 376A218542391 for ; Mon, 28 Aug 2006 15:13:49 +0200 (CEST) Message-ID: <44F2EC0C.7090407@logix-tt.com> Date: Mon, 28 Aug 2006 15:13:48 +0200 From: Markus Schaber Organization: Logical Tracking and Tracing International AG, Switzerland User-Agent: Thunderbird 1.5.0.4 (X11/20060713) MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: perf pb solved only after pg_dump and restore References: <8764gd1dkz.fsf@meuh.mnc.lan> <44F2B737.7070301@logix-tt.com> <87sljhyz4b.fsf@meuh.mnc.lan> <1d4e0c10608280317i4eb9d7d0r2b397845ffb8c19d@mail.gmail.com> <874pvxyrbg.fsf@meuh.mnc.lan> In-Reply-To: <874pvxyrbg.fsf@meuh.mnc.lan> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.168 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200608/427 X-Sequence-Number: 20612 Hi, Guillaume, Guillaume Cottenceau wrote: > About REINDEX: is it ok to consider that REINDEX is to indexes > what VACUUM FULL is to table data, because it cleans up unused > index pages? Yes, roughly speaking. >> And AFAICS you're not running it on a regular basis so your database >> was probably completely bloated which means: >> - bloated indexes, >> - bloated tables (ie a lot of fragmentation in the pages which means >> that you need far more pages to store the same data). > > I suppose that table fragmentation occurs when DELETE are > interleaved with INSERT? Yes, and it gets ugly as soon as the fsm setting is to low / VACUUM frequency is to low, so it cannot keep up. Big bunches of UPDATE/DELETE that hit more than, say 20% of the table between VACUUM runs, justify a VACUUM FULL in most cases. > VACUUM ANALYZE is normally run overnight (each night). Is it not > regular enough? There can be hundreds of thousands of statements > a day. Which PostgreSQL version are you using? Maybe you should consider autovacuum (which is a contrib module at least since 7.4, and included in the server since 8.1). If you think that vacuum during working hours puts too much load on your server, there are options to tweak that, at least in 8.1. Markus -- Markus Schaber | Logical Tracking&Tracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org