Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index

Thanks to everyone, pushed

Andrey Borodin wrote:
> 
> 
>> 27 марта 2018 г., в 13:45, Alexander Korotkov <a.korotkov@postgrespro.ru 
>> <mailto:a.korotkov@postgrespro.ru>> написал(а):
>>
>> On Tue, Mar 27, 2018 at 11:16 AM, Andrey Borodin <x4mmm@yandex-team.ru 
>> <mailto:x4mmm@yandex-team.ru>> wrote:
>>
>>     > 27 марта 2018 г., в 12:53, Teodor Sigaev <teodor@sigaev.ru
>>     <mailto:teodor@sigaev.ru>> написал(а):
>>     >
>>     > I have a question: why do not CheckForSerializableConflictIn() move  into begining of gistplacetopage()?
Seems,it is the single
 
>>     function which actually changes page and all predicate locking stuff will
>>     be placed in single function...
>>
>>     gistplacetopage() is called from
>>     1. Buffered build - probably harmless
>>
>>
>> Yes, harmless, but useless.
>>
>>     2. Finish split - i'm not sure about this. It seems to me that it is
>>     necessary... then your version is correct.
>>
>>
>> Yes, it's necessary, because GiST scan can end up on non-leaf page.  So, scan 
>> and modify of same non-leaf page should conflict.
>>
>> Checking for serializable conflicts from buffering build seems useless 
>> overhead.  gistplacetopage()
>> is called from only two places: gistinserttuples() 
>> and gistbufferinginserttuples().  In order to evade
>> useless overhead for buffering build, I've moved 
>> CheckForSerializableConflictIn() into gistinserttuples().
> +1
> Also, both gistdoinsert() and gistplacetopage() are mind blowing in complexity. 
> gistinserttuples() looks like a cosy place if we need to add some more.
> 
> Best regards, Andrey Borodin.

-- 
Teodor Sigaev                                   E-mail: teodor@sigaev.ru
                                                    WWW: http://www.sigaev.ru/