Message-ID: <490739F6.3040103@enterprisedb.com>
Date: Tue, 28 Oct 2008 18:12:38 +0200
Organization: EnterpriseDB
User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: Simon Riggs <simon@2ndQuadrant.com>
CC: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Updating FSM on recovery
References: <49072021.7010801@enterprisedb.com>
	<1225208150.3971.191.camel@ebony.2ndQuadrant>
In-Reply-To: <1225208150.3971.191.camel@ebony.2ndQuadrant>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

Simon Riggs wrote:
> On Tue, 2008-10-28 at 16:22 +0200, Heikki Linnakangas wrote:
> 
>> Arbitrarily, if after a 
>> heap insert/update there's less than 20% of free space on the page,
>> the FSM is updated. Compared to updating it every time, that saves a
>> lot of overhead, while doing a pretty good job at marking full pages
>> as full in  the FSM. My first thought was to update the FSM if there
>> isn't enough room on the page for a new tuple of the same size as the
>> one just 
>> inserted; that would be pretty close to the logic we have during
>> normal 
>> operation, where the FSM is updated when the tuple that we're about
>> to 
>> insert doesn't fit on the page. But because we don't know the
>> fillfactor 
>> during recovery, I don't think we can do reliably.
> 
> With HOT, we tend to hover around the nearly-full state, so this seems
> like it will trigger repeatedly.

Hmm, true. Perhaps we should skip updating the FSM on HOT updates. After 
recovery, the new HOT-updated tuples are prunable anyway, so for 
inserting a new tuple, the page is almost as good as it was before the 
HOT update.

> Is it possible that we could put an extra field onto a heap_clean record
> to show remaining space. We would use it only for VACUUMs, not HOT, just
> as we do now.

Sure, we could do that. I'm more worried about "killing" the pages from 
the FSM that are full, though, than keeping track of pages with plenty 
of free space accurately.

> I wonder if there is merit in having an XLogInsertMulti() which inserts
> multiple records in a batch as a way of reducing WALInsertLock traffic.
> It might be possible to piggyback FSM records onto the main heap
> changes.

Umm, in the version that was finally committed, FSM doesn't generate any 
extra WAL records (except for truncation).

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com