From: Heikki Linnakangas <heikki@enterprisedb.com>
To: pgsql-patches <pgsql-patches@postgresql.org>
Subject: Relation forks & FSM rewrite patches
Date: Fri, 27 Jun 2008 19:36:50 +0300
Message-ID: <48651722.8020600@enterprisedb.com> (raw)
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.comAttachments:
fsm-rewrite-1.patch.gz (application/x-gzip, 44.1K) download
relforks-1.patch.gz (application/x-gzip, 22.6K) download
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: heikki@enterprisedb.com
Subject: Re: Relation forks & FSM rewrite patches
In-Reply-To: <48651722.8020600@enterprisedb.com>
* 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