3. Multi extend patch attached in the mail. #extend_num_pages : This this new config parameter to tell how many extra page extend in case of normal extend..
may be it will give more control to user if we make it relation property.
I will work on the patch for this CF, so adding it to CF.
Shared Buffer 48 GB
Clients
Base (TPS)
Lock Free Patch
Multi-extend extend_num_pages=5
1
142
138
148
2
251
253
280
4
237
416
464
8
168
491
575
16
141
448
404
32
122
337
332
Shared Buffer 64 MB
Clients
Base (TPS)
Multi-extend extend_num_pages=5
1
140
148
2
252
266
4
229
437
8
153
475
16
132
364
I'm not really sure what this email is trying to say.
What I could understand from above e-mail is that Dilip has tried to
extend relation multiple-pages-at-a-time and observed that it gives
comparable or better performance as compare to Andres's idea of
lock-free extension and it doesn't regress the low-thread count case.
Now, I think here point to discuss is that there could be multiple-ways
for extending a relation multiple-pages-at-a-time like:
a. Extend the relation page by page and add it to FSM without initializing
it. I think this is what the current patch of Dilip seems to be doing. If we
want to go via this route, then we need to ensure that whenever we get
the page from FSM, if it is empty and not initialised, then initialise it.
b. Extend the relation page by page, initialize it and add it to FSM.
c. Extend the relation *n* pages at a time (in mdextend, have a provision
to do FILEWRITE for multiples of BLCKSZ). Here again, we need to
evaluate what is better way to add it to FSM (after Page initialization or
before page initialization).
d. Use some form of Group Extension, which means only one backend
will extend the relation and others will piggyback there request of
