Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 5090B37C053 for ; Mon, 29 Sep 2008 09:33:42 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 32504-03 for ; Mon, 29 Sep 2008 09:33:35 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by postgresql.org (Postfix) with ESMTP id D4A0337BA3A for ; Mon, 29 Sep 2008 09:33:35 -0300 (ADT) Received: by ey-out-2122.google.com with SMTP id 6so519198eyi.61 for ; Mon, 29 Sep 2008 05:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=TGrMX7qmcgK3FM+T+eE7WLxTv+xzG1bsR7SKYOMnud4=; b=I6NDe8/5SSA+8C8iAhbtkEuasPqLL++dtTa15T64nyoz84rOrqIdt7gkgdFDSmumjL f0ltY3a7bo9EDysVLmsLXZQuBjL9DxQnSBJmrBTmBqFwovLi1+IbYddDcPFhGXX+GCuF /WZzjYozqeH2PO7geU9T2WV1I4rKTeBBSBwes= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Emhi42KGjBlcMC9/BRQTBcG2HIqBp+g23HSQgCRXF3PmIw8ljf8EWV09ZU6sxMr8pk gEwp64kKLBYvhzgel0HkQZuupWdWmXfKBqSjWw4xjRTutSxlQNlLhndfo/rmQidcxzRK PaQeidEliyXEc7I/U3siSXspNMg3x/6agdryA= Received: by 10.210.23.3 with SMTP id 3mr6143104ebw.188.1222691612817; Mon, 29 Sep 2008 05:33:32 -0700 (PDT) Received: by 10.210.43.4 with HTTP; Mon, 29 Sep 2008 05:33:32 -0700 (PDT) Message-ID: Date: Mon, 29 Sep 2008 14:33:32 +0200 From: "Peter Kovacs" To: "Tom Lane" Subject: Re: Do we need vacuuming when tables are regularly dropped? Cc: pgsql-admin@postgresql.org In-Reply-To: <9815.1222690583@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <9815.1222690583@sss.pgh.pa.us> X-Google-Sender-Auth: 659d2138b68ec01b X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200809/331 X-Sequence-Number: 30424 On Mon, Sep 29, 2008 at 2:16 PM, Tom Lane wrote: > "Peter Kovacs" writes: >> We have a number of automated performance tests (to test our own code) >> involving PostgreSQL. Test cases are supposed to drop and recreate >> tables each time they run. > >> The problem is that some of the tests show a linear performance >> degradation overtime. (We have data for three months back in the >> past.) We have established that some element(s) of our test >> environment must be the culprit for the degradation. As rebooting the >> test machine didn't revert speeds to baselines recorded three months >> ago, we have turned our attention to the database as the only element >> of the environment which is persistent across reboots. Recreating the >> entire PGSQL cluster did cause speeds to revert to baselines. > > What it sounds like to me is that you're not vacuuming the system > catalogs, which are getting bloated with dead rows about all those > dropped tables. Wow, great! It is not immediately clear from the documentation, but the VACUUM command also deals with the system catalogs as well, correct? Thanks a lot! Peter > > regards, tom lane >