Received: from localhost (unknown [200.46.204.184]) by developer.postgresql.org (Postfix) with ESMTP id D3A3F2E004A for ; Tue, 29 Apr 2008 02:47:09 -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 31283-10 for ; Tue, 29 Apr 2008 02:47:04 -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.28]) by developer.postgresql.org (Postfix) with ESMTP id BE92B2E0040 for ; Tue, 29 Apr 2008 02:47:06 -0300 (ADT) Received: by yw-out-2324.google.com with SMTP id 5so1600007ywb.73 for ; Mon, 28 Apr 2008 22:47:06 -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=/KiAmVMh+AAedn+U/xDhkbnDJgijPJwymy/53IipynU=; b=olfnfciNck/ZHQasAlxOJ0D62j8qp81F6fskGl7ZOCJD0mFn4eVacCF13q67TjFy7ipanKhadmTHwoQnPcupPifljKYm/KfYejK0VqUSbbc9L/QKeiVfjQ+/o3mvoOBDRFgXVckZfgpkCb3jtyIMtyfznJqus3MoejGF3BRR7Q0= 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=q/0cK7G8Ke5xhPEGELB+hK24mdzKsES1AgpxC2lk2lUf8zLJ7ZT4Ruz7othH4FCYKpRT69W+v3BBg7xkfGAINCuVn42WWoeavBhtWj529puB1RysLbbIEt49E+Cz4x1NV1hlwpnPwIQ8vu/s7NlvuzSCG3v47wTnTXZi0l+BtbE= Received: by 10.150.79.41 with SMTP id c41mr4685905ybb.231.1209448026058; Mon, 28 Apr 2008 22:47:06 -0700 (PDT) Received: by 10.151.84.7 with HTTP; Mon, 28 Apr 2008 22:47:05 -0700 (PDT) Message-ID: <2e78013d0804282247x35c0b796v80e77206c3b40489@mail.gmail.com> Date: Tue, 29 Apr 2008 11:17:05 +0530 From: "Pavan Deolasee" To: "Gauri Kanekar" Subject: Re: Replication Syatem Cc: "Greg Smith" , pgsql-performance@postgresql.org In-Reply-To: <7e4ba9550804282211s5568dc75l557e057fd1c33c2@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> <60wsmh64f6.fsf@dba2.int.libertyrms.com> <7e4ba9550804282155u655e3ab5o38d2e659b485530d@mail.gmail.com> <7e4ba9550804282211s5568dc75l557e057fd1c33c2@mail.gmail.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.329 tagged_above=0 required=5 tests=AWL=-1.570, FS_REPLICA=1.179, SARE_SPEC_REPLICA=0.72 X-Spam-Level: X-Archive-Number: 200804/425 X-Sequence-Number: 29918 On Tue, Apr 29, 2008 at 10:41 AM, Gauri Kanekar wrote: > But unless we do full vacuum the space is not recovered. Thats y we prefer > full vacuum. There is no point in recovering the space by moving tuples and truncating the relation (that's what VACUUM FULL does) because you are doing frequent updates on the table and that would again extend the relation. If you run plain VACUUM, that would recover dead space and update the free space maps. It may not be able to reduce the table size, but you should not be bothered much about it because the following updates/inserts will fill in the fragmented free space. You may want to check your FSM settings as well to make sure that you are tracking free space properly. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com