Fwd: GSoC 2017 Proposal for "Explicitly support predicate locks in index access methods besides btree"

---------- Forwarded message ----------
From: anant khandelwal <anantbietec(at)gmail(dot)com>
Date: Mon, Apr 3, 2017 at 11:13 PM
Subject: Re: [HACKERS] GSoC 2017 Proposal for "Explicitly support predicate
locks in index access methods besides btree"
To: Kevin Grittner <kgrittn(at)gmail(dot)com>

First ,I have read from this

https://github.com/postgres/postgres/blob/master/src/
backend/storage/lmgr/README-SSI ------Other Index AM implementation

then i understand that at https://github.com/postgres/postgres/tree/master/
src/backend/access/gist--------

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 -----

https://github.com/postgres/postgres/blob/master/src/backend/access/nbtree/
nbtinsert.c

PredicateLockPageSplit(rel,BufferGetBlockNumber(buf),
BufferGetBlockNumber(rbuf));

then i find how PredicateLockPage is called from --------https://github.com/
postgres/postgres/blob/master/src/backend/access/nbtree/nbtsearch.c

then i find how CheckPredicateLocking() is locking is implemented -----

https://github.com/postgres/postgres/blob/master/src/backend/access/nbtree/
nbtinsert.c

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.

then gistScanPage() ----- https://github.com/postgres/postgres/blob/master/
src/backend/access/gist/gistget.c

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

On Mon, Apr 3, 2017 at 10:03 PM, Kevin Grittner <kgrittn(at)gmail(dot)com> wrote:

> On Sat, Apr 1, 2017 at 9:03 AM, anant khandelwal <anantbietec(at)gmail(dot)com>
> wrote:
>
> > My name is Anant Khandelwal currently i am pursuing masters from IIT -
> Delhi
> > and previously i am a software engineer.
> >
> > I am particularly interested in working on the project "Explicitly
> support
> > predicate locks in index access methods besides b tree".
>
> Anant,
>
> Your post was mostly identical (as in copy/paste level identical) to a
> post by Shubham Barai four days earlier.
>
> https://www.postgresql.org/message-id/CALxAEPvRcJzz0SJ2KB_gh
> aTRrdEj08rygUrFtr5NUQxc6uTeuQ(at)mail(dot)gmail(dot)com
>
> https://www.postgresql.org/message-id/CAD=a8SBZWGD4U-TASJP0O
> wTPiLEffHoz5O5eV0Um6digqBVvfg(at)mail(dot)gmail(dot)com
>
> Unless you can produce convincing proof to the contrary, your proposal
> will be disqualified because of plagiarism.
>
> --
> Kevin Grittner
>