On Mon, Mar 28, 2016 at 1:55 AM, Robert Haas <robertmh...@gmail.com> wrote:
> > 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 ?
I will test and post the result with this option.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
