GSoC 2017: weekly progress reports (week 5) and Proposal for predicate locking in gin index

Project: Explicitly support predicate locks in index AMs besides b-tree

Hi,

During this week, I read documentation and source code of gin index to find
appropriate places to insert calls to existing functions.

Proposal

Gin index consists of a Btree index over key values, where each key is an
element of some indexed items and each tuple in a leaf page contains either
a posting list if the list is small enough or a pointer to posting tree.
As gin searches have to go all the way to leaf pages to determine whether
there is a match or not, we just need a predicate lock on leaf pages.

Also, gin index has a feature called fast update which postpones the
insertion of tuples by temporarily storing them into pending list. The
pending list is eventually flushed during vacuum. So this creates a problem
because even if a scan acquires a page level predicate lock on the pending
list, we will not be able to detect r-w conflict because a new insert will
just append tuples on the pending list. So, I think if a fast update is
enabled, we need a predicate lock on the entire relation.

The possible places where we need to insert calls to existing
functions are as follows

1. PredicateLockPage()

-> entryLoadMoreItems()

->startscanentry()
before calling collectMatchBitmap()

>scanPostingTree()
after acquiring a shared lock on a leaf page

2. CheckForSerializableConflictIn()

->ginentryinsert()

->gininsertitempointers()
in case of insertion in a posting tree

3. PredicateLockPageSplit()

->dataBeginPlacetoPageLeaf()
after calling dataPlacetoPageLeafSplit()

<https://mailtrack.io/> Sent with Mailtrack
<https://mailtrack.io/install?source=signature&lang=en&referral=shubhambaraiss(at)gmail(dot)com&idSignature=22>