Skip site navigation (1) Skip section navigation (2)

Relation forks & FSM rewrite patches

From: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
To: "pgsql-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Relation forks & FSM rewrite patches
Date: 2008-06-27 16:36:50
Message-ID: 48651722.8020600@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-patches
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.com

Attachment: relforks-1.patch.gz
Description: application/x-gzip (22.6 KB)
Attachment: fsm-rewrite-1.patch.gz
Description: application/x-gzip (44.1 KB)

Responses

pgsql-patches by date

Next:From: Hiroshi SaitoDate: 2008-06-27 16:40:03
Subject: win32mak of libpq patch
Previous:From: Heikki LinnakangasDate: 2008-06-27 16:04:50
Subject: Re: [HACKERS] Hint Bits and Write I/O

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group