database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-08-17 01:02:17 +03:00
Code Activity

Predicate locking in GIN index

Browse Source 
Predicate locks are used on per page basis only if fastupdate = off, in
opposite case predicate lock on pending list will effectively lock whole index,
to reduce locking overhead, just lock a relation. Entry and posting trees are
essentially B-tree, so locks are acquired on leaf pages only.

Author: Shubham Barai with some editorization by me and Dmitry Ivanov
Review by: Alexander Korotkov, Dmitry Ivanov, Fedor Sigaev
Discussion: https://www.postgresql.org/message-id/flat/CALxAEPt5sWW+EwTaKUGFL5_XFcZ0MuGBcyJ70oqbWqr42YKR8Q@mail.gmail.com
This commit is contained in:
Teodor Sigaev
2018-03-30 14:23:17 +03:00
parent 019fa576ca
commit 43d1ed60fd
11 changed files with 1054 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
src/backend/storage/lmgr/README-SSI
View File

@@ -380,6 +380,15 @@ then be trusted to ripple up to all levels and locations where
conflicting predicate locks may exist. In case there is a page split,
we need to copy predicate lock from an original page to all new pages.
* GIN searches acquire predicate locks only on the leaf pages
of entry tree and posting tree. During a page split, a predicate locks are
copied from the original page to the new page. In the same way predicate locks
are copied from entry tree leaf page to freshly created posting tree root.
However, when fast update is enabled, a predicate lock on the whole index
relation is required. Fast update postpones the insertion of tuples into index
structure by temporarily storing them into pending list. That makes us unable
to detect r-w conflicts using page-level locks.
* The effects of page splits, overflows, consolidations, and
removals must be carefully reviewed to ensure that predicate locks
aren't "lost" during those operations, or kept with pages which could