Re: [HACKERS] GSoC 2017 : Proposal for predicate locking in gist index
От | Andrew Borodin |
---|---|
Тема | Re: [HACKERS] GSoC 2017 : Proposal for predicate locking in gist index |
Дата | |
Msg-id | CAJEAwVGQ_ptH-jFEsPBkDtGeHUr4P=uMLanFne+XuXN9CQpk8g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] GSoC 2017 : Proposal for predicate locking in gist index (Kevin Grittner <kgrittn@gmail.com>) |
Ответы |
Re: [HACKERS] GSoC 2017 : Proposal for predicate locking in gist index
|
Список | pgsql-hackers |
Hi, hackers! 2017-06-01 1:50 GMT+05:00 Kevin Grittner <kgrittn@gmail.com>: > > The main difference between b-tree and gist index while searching for a > > target tuple is that in gist index, we can determine if there is a match or > > not at any level of the index. > > Agreed. A gist scan can fail at any level, but for that scan to > have produced a different result due to insertion of an index entry, > *some* page that the scan looked at must be modified. Two things seem non-obvious to me. First, I just do not know, can VACUUM erase page with predicate lock? Right now, GiST never deletes pages, as far as I know, so this question is only matter of future compatibility. Second, when we are doing GiST inserts, we can encounter unfinished split. That's not a frequent situation, but still. Should we skip finishing split or should we add it to collision check too? Best regards, Andrey Borodin, Octonica.
В списке pgsql-hackers по дате отправления: