From: Mark Kirkwood <markir@paradise.net.nz>
To: Heikki Linnakangas <heikki@enterprisedb.com>
Cc: pgsql-patches <pgsql-patches@postgresql.org>
Subject: Re: Relation forks & FSM rewrite patches
Date: Fri, 04 Jul 2008 15:23:51 +1200
Message-ID: <486D97C7.2070204@paradise.net.nz> (raw)
In-Reply-To: <48651722.8020600@enterprisedb.com>
References: <48651722.8020600@enterprisedb.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-patches@postgresql.org
Cc: markir@paradise.net.nz, heikki@enterprisedb.com
Subject: Re: Relation forks & FSM rewrite patches
In-Reply-To: <486D97C7.2070204@paradise.net.nz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox