Relation forks & FSM rewrite patches
От | Heikki Linnakangas |
---|---|
Тема | Relation forks & FSM rewrite patches |
Дата | |
Msg-id | 48651722.8020600@enterprisedb.com обсуждение исходный текст |
Ответы |
Re: Relation forks & FSM rewrite patches
Re: Relation forks & FSM rewrite patches Re: Relation forks & FSM rewrite patches |
Список | 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
Вложения
В списке pgsql-patches по дате отправления: