Fwd: GSoC 2017 Proposal for "Explicitly support predicatelocks in index access methods besides btree"
| От | anant khandelwal |
|---|---|
| Тема | Fwd: GSoC 2017 Proposal for "Explicitly support predicatelocks in index access methods besides btree" |
| Дата | |
| Msg-id | CAD=a8SDotUoLZt+_fCndSAi=rq2XcGye8Bp-gvFMrikNfvcctw@mail.gmail.com обсуждение исходный текст |
| Ответ на | GSoC 2017 Proposal for "Explicitly support predicate locks in indexaccess methods besides btree" (anant khandelwal <anantbietec@gmail.com>) |
| Список | pgsql-hackers |
---------- Forwarded message ----------
From: anant khandelwal <anantbietec@gmail.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@gmail.com>
From: anant khandelwal <anantbietec@gmail.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@gmail.com>
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.
PredicateLockPageSplit(rel,
Scan all items on the GiST index page identified by *pageItem, and insert
* them into the queue (or directly to output areas)
https://github.com/postgres/
then i understand that at https://github.com/
then i look at how btree does that it does that by having a function -----
then i find how PredicateLockPage is called from --------https://github.com/
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.
* 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/
* 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@gmail.com> wrote:
On Sat, Apr 1, 2017 at 9:03 AM, anant khandelwal <anantbietec@gmail.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@ mail.gmail.com
https://www.postgresql.org/message-id/CAD=a8SBZWGD4U-TASJP0O wTPiLEffHoz5O5eV0Um6digqBVvfg@ mail.gmail.com
Unless you can produce convincing proof to the contrary, your proposal
will be disqualified because of plagiarism.
--
Kevin Grittner
В списке pgsql-hackers по дате отправления: