Re: GSoC 2017 : Proposal for predicate locking in gist index

Hi, Kevin sir!

On 1 June 2017 at 02:20, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:

> On Wed, May 31, 2017 at 3:02 PM, Shubham Barai <shubhambaraiss(at)gmail(dot)com>
> wrote:
>
> > I have been accepted as GSoC student for the project "Explicitly support
> > predicate locks in index access methods besides b-tree". I want to share
> my
> > approach for implementation of page level predicate locking in gist
> index.
>
> For the benefit of all following the discussion, implementing
> support in an index AM conceptually consists of two things:
> (1) Any scan with user-visible results must create SIRead predicate
> locks on "gaps" scanned. (For example, a scan just to find an
> insertion spot for an index entry does not generally count, whereas
> a scan to satisfy a user "EXISTS" test does.)
> (2) Any insert into the index must CheckForSerializableConflictIn()
> at enough points that at least one of them will detect an overlap
> with a predicate lock from a preceding scan if the inserted index
> entry might have changed the results of that preceding scan.
>
> Detecting such a conflict does not automatically result in a
> serialization failure, but is only part of tracking the information
> necessary to make such a determination. All that is handled by the
> existing machinery if the AM does the above.
>
> With a btree index, locking gaps at the leaf level is normally
> sufficient, because both scan and insertion of an index entry must
> descend that far.
>
> > The main difference between b-tree and gist index while searching for a
> > target tuple is that in gist index, we can determine if there is a match
> or
> > not at any level of the index.
>
> Agreed. A gist scan can fail at any level, but for that scan to
> have produced a different result due to insertion of an index entry,
> *some* page that the scan looked at must be modified.
>
> > The simplest way to do that will be by inserting a call for
> > prdicatelockpage() in gistscanpage().
>
> Yup.
>
> > Insertion algorithm also needs to check for conflicting predicate locks
> at
> > each level of the index.
>
> Yup.
>
> > We can insert a call for CheckForSerializableConflictIn() at two places
> in
> > gistdoinsert().
> >
> > 1. after acquiring an exclusive lock on internal page (in case we are
> trying
> > to replace an old search key)
> >
> > 2. after acquiring an exclusive lock on leaf page
> >
> > If there is not enough space for insertion, we have to copy predicate
> lock
> > from an old page to all new pages generated after a successful split
> > operation. For that, we can insert a call for PredicateLockPageSplit() in
> > gistplacetopage().
>
> That all sounds good. When you code a patch, don't forget to add
> tests to src/test/isolation.
>

> Do you need any help getting a development/build/test environment
> set up?
>

Yes, any link to the documentation will be helpful.

>
> --
> Kevin Grittner
> VMware vCenter Server
> https://www.vmware.com/
>