Subject: Re: [HACKERS] GSoC 2017 Proposal for "Explicitly support predicate locks in index access methods besides btree"
First ,I have read from this
gistplacetopage is the workhorse function that performs one step of the insertion. If the tuple fits, it inserts it to the given page, otherwise it splits the page, and constructs the new downlink tuples for the split pages. The caller must then call gistplacetopage() on the parent page to insert the downlink tuples.
then i look at how btree does that it does that by having a function -----
PredicateLockPageSplit(rel,
BufferGetBlockNumber(buf),
BufferGetBlockNumber(rbuf));
then i find how CheckPredicateLocking() is locking is implemented -----
The only conflict predicate locking cares about for indexes is when
* an index tuple insert conflicts with an existing lock. Since the
* actual location of the insert is hard to predict because of the
* random search used to prevent O(N^2) performance when there are
* many duplicate entries, we can just use the "first valid" page.
Scan all items on the GiST index page identified by *pageItem, and insert
* them into the queue (or directly to output areas)
So we need to put the predicateLockPage() there
I think i have provided sufficient proof for the Index AM gist if you want i can give proof for all other ones also.
Thanks
Anant