| From: | Andrew Borodin <borodin(at)octonica(dot)com> |
|---|---|
| To: | Kevin Grittner <kgrittn(at)gmail(dot)com> |
| Cc: | Shubham Barai <shubhambaraiss(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Andrew Borodin <amborodin86(at)gmail(dot)com> |
| Subject: | Re: GSoC 2017 : Proposal for predicate locking in gist index |
| Date: | 2017-06-01 05:49:04 |
| Message-ID: | CAJEAwVGQ_ptH-jFEsPBkDtGeHUr4P=uMLanFne+XuXN9CQpk8g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi, hackers!
2017-06-01 1:50 GMT+05:00 Kevin Grittner <kgrittn(at)gmail(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2017-06-01 05:49:32 | Re: Error while creating subscription when server is running in single user mode |
| Previous Message | Masahiko Sawada | 2017-06-01 04:48:54 | Tweaking tab completion for some backslash commands |