Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id BEFD764FCD4 for ; Fri, 4 Jul 2008 16:32:14 -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 76397-07 for ; Fri, 4 Jul 2008 16:32:08 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail01.enterprisedb.com (webmail.enterprisedb.com [63.246.7.168]) by postgresql.org (Postfix) with ESMTP id 0094A64FCD3 for ; Fri, 4 Jul 2008 16:32:10 -0300 (ADT) thread-index: AcjeDMSDta5sQreJRKOc4eZVB6A6KA== Content-Class: urn:content-classes:message Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4133 Received: from [80.222.70.18] ([80.222.70.18]) by mail01.enterprisedb.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jul 2008 15:32:59 -0400 Message-ID: <486E7AB6.40804@enterprisedb.com> Date: Fri, 04 Jul 2008 22:32:06 +0300 From: "Heikki Linnakangas" Organization: EnterpriseDB User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: "Alvaro Herrera" Cc: "Simon Riggs" , "pgsql-patches" Subject: Re: Relation forks & FSM rewrite patches References: <48651722.8020600@enterprisedb.com> <1215161814.4051.36.camel@ebony.site> <486DED1B.4020202@enterprisedb.com> <1215169844.4051.95.camel@ebony.site> <486E159D.2050405@enterprisedb.com> <20080704163643.GB3893@alvh.no-ip.org> In-Reply-To: <20080704163643.GB3893@alvh.no-ip.org> Content-Type: text/plain; format=flowed; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Jul 2008 19:32:59.0671 (UTC) FILETIME=[C4700A70:01C8DE0C] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200807/76 X-Sequence-Number: 6770 Alvaro Herrera wrote: > I wonder if we could instead make vacuum write a new FSM tree from > scratch, rather than updating it piecemeal. I'd like to move away from that, as we'll hopefully get some sort of partial vacuum capability soon. We might want to have some sort of bulk update operation, though, so that you could refresh FSM information for say 100 pages, or one FSM page, at a time. That would reduce the WAL traffic of a VACUUM significantly, though I'm not sure how significant that is to begin with. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com