Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id A2A909FB80A for ; Tue, 8 May 2007 08:00:19 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 47336-08 for ; Tue, 8 May 2007 08:00:03 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4 Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by postgresql.org (Postfix) with ESMTP id E65F89FB7FC for ; Tue, 8 May 2007 08:00:12 -0300 (ADT) Received: by ug-out-1314.google.com with SMTP id k3so61792ugf for ; Tue, 08 May 2007 04:00:11 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=qzOyRbOkjykiOZTTcnT5LatECC0KJUq+aDTSrY4LrBFV2cUJUS86IRW18WTOGbShA0Sm1+AaQeuAdX076gi6hD1VqEAVcV+7/eUZKZdcDoIhBQQ/gKa0QtKKfVgkm4IlO2V6jlcg1eedxuiD3E5/+lP2Ied0dCIB8OLni0sEz4c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:sender; b=hnFgbnyNi01kFoPy5LqgR6Fr4Yen8Pw8JusM7RbDtlXOzvL5hm020pInPkDnZjnbAognl99gDVm5H1cJbumOck74vvEFSK7OsKJez6dZMtn5yg3XZCVPnPpzZGIoPc8u+IZh9ulaaNWCtjzBqL489ex3ZSESlcV3Mbm+ssMDOkA= Received: by 10.66.225.1 with SMTP id x1mr425542ugg.1178622011269; Tue, 08 May 2007 04:00:11 -0700 (PDT) Received: from ?172.24.32.83? ( [62.232.55.118]) by mx.google.com with ESMTP id 54sm616139ugp.2007.05.08.04.00.09; Tue, 08 May 2007 04:00:09 -0700 (PDT) Message-ID: <46405824.9010000@enterprisedb.com> Date: Tue, 08 May 2007 11:59:48 +0100 From: Heikki Linnakangas User-Agent: Icedove 1.5.0.10 (X11/20070329) MIME-Version: 1.0 To: Pomarede Nicolas CC: pgsql-performance@postgresql.org Subject: Re: truncate a table instead of vaccum full when count(*) is 0 References: <46404BEA.5060009@enterprisedb.com> <464052DB.30206@enterprisedb.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200705/108 X-Sequence-Number: 24498 Pomarede Nicolas wrote: > There's not too much simultaneous transaction on the database, most of > the time it shouldn't exceed one minute (worst case). Except, as I need > to run a vacuum analyze on the whole database every day, it now takes 8 > hours to do the vacuum (I changed vacuum values to be a little slower > instead of taking too much i/o and making the base unusable, because > with default vacuum values it takes 3-4 hours of high i/o usage (total > base is 20 GB) ). > > So, at this time, the complete vacuum is running, and vacuuming only the > spool table gives all dead rows are currently not removable (which is > normal). Oh, I see. I know you don't want to upgrade, but that was changed in 8.2. Vacuum now ignores concurrent vacuums in the oldest xid calculation, so the long-running vacuum won't stop the vacuum on the spool table from removing dead rows. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com