Date: Fri, 04 Jul 2008 15:23:51 +1200
From: Mark Kirkwood <markir@paradise.net.nz>
Subject: Re: Relation forks & FSM rewrite patches
In-reply-to: <48651722.8020600@enterprisedb.com>
To: Heikki Linnakangas <heikki@enterprisedb.com>
Cc: pgsql-patches <pgsql-patches@postgresql.org>
Message-id: <486D97C7.2070204@paradise.net.nz>
MIME-version: 1.0
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7bit
References: <48651722.8020600@enterprisedb.com>
User-Agent: Thunderbird 2.0.0.14 (X11/20080601)

Heikki Linnakangas wrote:
> Here's an updated version of the "relation forks" patch, and an 
> incremental FSM rewrite patch on top of that. The relation forks patch 
> is ready for review. The FSM implementation is more work-in-progress 
> still, but I'd like to get some review on that as well, with the goal 
> of doing more performance testing and committing it after the commit 
> fest.
>
> The one part that I'm not totally satisfied in the relation forks 
> patch is the smgrcreate() function. The question problem is: which 
> piece of code decides which forks to create for a relation, and when 
> to create them? I settled on the concept that all forks that a 
> relation will need are created at once, in one smgrcreate() call. 
> There's no function to create additional forks later on. Likewise, 
> there's no function to unlink individual forks, you have to unlink the 
> whole relation.
>
> Currently, heap_create() decides which forks to create. That's fine at 
> the moment, but will become problematic in the future, as it's 
> indexam-specific which forks an index requires. That decision should 
> really be done in the indexam. One possibility would be to only create 
> the main fork in heap_create(), and let indexam create any additional 
> forks it needs in ambuild function.
>

I've had a bit of a play with this, looks pretty nice. One point that 
comes to mind is that we are increasing the number of required file 
descriptors by a factor of 2 (and possibly 3 if we use a fork for the 
visibility map). Is this a problem do you think?

Cheers

Mark