Re: Relation extension scalability

On Thu, Jan 7, 2016 at 1:36 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Thu, Dec 31, 2015 at 6:22 AM, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
> wrote:
>
>>
>> *Performanec Data:*
>> --------------------------
>> *There are Three code base for performance*
>> 1. Base Code
>>
>> 2. Lock Free Patch : patch given in below thread
>> *http://www.postgresql.org/message-id/20150719140746.GH25610@awork2.anarazel.de
>> <http://www.postgresql.org/message-id/20150719140746.GH25610@awork2.anarazel.de>*
>>
>> 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
extension to that backend and wait for extension.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com