> One is like below--> > ------------------------- > In AddExtraBlock > { > I add page to FSM one by one like v13 does. > then update the full FSM tree up till root > }
Not following this. Did you attach this version?
No I did not attached this.. During rough experiment, tried this, did not produced any patch, I will send this.
> Results: > ---------- > 1. With this performance is little less than v14 but the problem of extra > relation size is solved. > 2. With this we can conclude that extra size of relation in v14 is because > some while extending the pages, its not immediately available and at end > some of the pages are left unused.
I agree with that conclusion. I'm not quite sure where that leaves us, though. We can go back to v13, but why isn't that producing extra pages? It seems like it should: whenever a bulk extend rolls over to a new FSM page, concurrent backends will search either the old or the new one but not both.
Maybe we could do this - not sure if it's what you were suggesting above:
1. Add the pages one at a time, and do RecordPageWithFreeSpace after each one. 2. After inserting them all, go back and update the upper levels of the FSM tree up the root.
Yes same, I wanted to explained the same above.
Another idea is:
If ConditionalLockRelationForExtension fails to get the lock immediately, search the last *two* pages of the FSM for a free page.
Just brainstorming here.
I think this is better option, Since we will search last two pages of FSM tree, then no need to update the upper level of the FSM tree. Right ?
