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
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
