[HACKERS] GSoC 2017: weekly progress reports (week 5) and Proposal forpredicate locking in gin index - Mailing list pgsql-hackers
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
-> 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()
pgsql-hackers by date: