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  (Kevin Grittner <kgrittn@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Masahiko Sawada
Дата:
Сообщение: [HACKERS] Tweaking tab completion for some backslash commands
Следующее
От: Dilip Kumar
Дата:
Сообщение: Re: [HACKERS] Error while creating subscription when server isrunning in single user mode