Heikki Lin****angas 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@[EMAIL PROTECTED]
)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
|
