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

Map forks (WIP)

From: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
To: "pgsql-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Map forks (WIP)
Date: 2008-04-29 10:42:19
Message-ID: 4816FB8B.9040104@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-patches
I've been experimenting with different ways to implement the map forks, 
for FSM and visibility map. Attached is my first attempt. I've hacked 
together an FSM implementation that uses a fork, to have something to 
test with, but the FSM implementation is still very much WIP, so please 
ignore freespace.c and indexfsm.c for now. The rest of the code is WIP 
as well, but it does compile and pass regression tests.

A relation fork is represented by PhysFileNode, which is 
RelFileNode+ForkNumber. smgr.c/md.c now deal with PhysFileNodes instead 
of RelFileNodes, as well as a bunch of other places related to that. 
Each fork gets its own SMgrRelation.

In RelationData, rd_smgr is now an array of SMgrRelations, one per fork. 
In bufmgr.c, there's a new variant of ReadBuffer that takes a ForkNumber 
as extra argument.

One difficulty is to decide when the extra forks are created and 
dropped. The way it works now is that for a heap, all the required forks 
(the main fork that contains the actual data and the FSM fork at the 
moment) are created in heap_create. In indexes, it's indexam-specific 
which forks are required, so only the main fork is created in 
heap_create, and it's up to the indexam build-function to create any 
additional forks if necessary. There's a few places, like 
copy_relation_data, that need to test which forks exist, so I've added a 
new smgrexists() function for that.

I was planning to refactor the WAL replay code so that the 
redo-functions would deal with SMgrRelations directly, and get rid of 
the lightweight relation cache in xlogutils.c. However, it turned out to 
be harder than I thought, because we use the same code in the redo 
cleanup functions that we do during normal operations. And we also use 
the lightweight relcache in BuildFlatFiles().

I'm not completely satisfied with the way this looks, so I'll try a 
slightly different approach next: Instead of having one SMgrRelation per 
fork, add an extra ForkNumber argument to all the smgr functions.

Any thoughts, ideas?

PS. If you're wondering what's taking me so long: I've been dragged into 
other stuff and haven't had much time to work on this :-(.

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

Attachment: fsm-forks-2.patch.gz
Description: application/x-gzip (56.2 KB)

Responses

pgsql-patches by date

Next:From: Magnus HaganderDate: 2008-04-29 11:40:23
Subject: Re: win32mak_patch
Previous:From: Bryce NesbittDate: 2008-04-29 04:43:59
Subject: Re: [HACKERS] Proposed patch - psql wraps at window width

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