Received: from localhost (unknown [200.46.204.184]) by developer.postgresql.org (Postfix) with ESMTP id 19B492E002D for ; Tue, 29 Apr 2008 02:55:32 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 43989-04 for ; Tue, 29 Apr 2008 02:55:26 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by developer.postgresql.org (Postfix) with ESMTP id BFF412E0062 for ; Tue, 29 Apr 2008 02:55:28 -0300 (ADT) Received: by yw-out-2324.google.com with SMTP id 5so1601141ywb.73 for ; Mon, 28 Apr 2008 22:55:28 -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:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=quX4jxTXuvfV2Bvesr4QLqSaFt34FZck0NGZ0Xhu5B0=; b=irjRv3ie2/07kiEzN0t+oGrjA4njpjjjsmbvCv9l3btx0VpfBU7UWWQ2r8OosbnyvI8Ygm6FcMUkkA/qiHfNYwTiife8YxLvGLwrWj4J43X0a0uxyFYKaspp0rCYCcaMzUigx6FDnaIs5fSgYWiDVQBBbVg74j35mFnqbNoCPIo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UXP0i4LRZymBepcDmEsUz8sQuCtwpM+GHNvAHmxWTa4SWAddSpDWXimCYmpOQlv3/SCAPqD7zzOda7d7FKn+3OVhix7Jk32+iVS4Q9vsioZWxfEaTdheMi/0xNDvX+lEGEGSeqpAfwhRFLj/C9c2LR1LgM1xKqn756IKL9+m5uI= Received: by 10.150.83.22 with SMTP id g22mr4698584ybb.140.1209448527978; Mon, 28 Apr 2008 22:55:27 -0700 (PDT) Received: by 10.151.84.7 with HTTP; Mon, 28 Apr 2008 22:55:27 -0700 (PDT) Message-ID: <2e78013d0804282255t48285141pf49d71bb63e8cf48@mail.gmail.com> Date: Tue, 29 Apr 2008 11:25:27 +0530 From: "Pavan Deolasee" To: "Gauri Kanekar" Subject: Re: Replication Syatem Cc: "Andrew Sullivan" , pgsql-performance@postgresql.org In-Reply-To: <7e4ba9550804282246p73c62fc6y5e7cb7dda55a6b50@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7e4ba9550804280638ie81dc23w472785c83cd38fcf@mail.gmail.com> <7e4ba9550804280705q43c51e66l104a5ff9272bbd4d@mail.gmail.com> <20080428162243.GN2970@commandprompt.com> <7e4ba9550804282246p73c62fc6y5e7cb7dda55a6b50@mail.gmail.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.381 tagged_above=0 required=5 tests=AWL=-1.518, FS_REPLICA=1.179, SARE_SPEC_REPLICA=0.72 X-Spam-Level: X-Archive-Number: 200804/426 X-Sequence-Number: 29919 On Tue, Apr 29, 2008 at 11:16 AM, Gauri Kanekar wrote: > Andrew, > > Can you explain me in detail why u said vacuum full is making the things > worst. 1. VACUUM FULL takes exclusive lock on the table. That makes table unavailable for read/writes. 2. VACUUM FULL moves live tuples around. When a tuple is moved, the old index entry is deleted and a new index entry is inserted. This causes index bloats which are hard to recover. > We do vacuum full, as vacuum verbose analyse dont regain space for us. > As I mentioned in the other reply, you are not gaining much by regaining space. The subsequent UPDATEs/INSERTs will quickly extend the relation and you loose all the work done by VACUUM FULL. Plain VACUUM will update FSM to track the free space scattered across the relation which is later reused by updates/inserts. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com