Thread: [HACKERS] GSoC 2017: weekly progress reports (week 7)
Project: Explicitly support predicate locks in index AMs besides b-treeHi,
During this week, I read documentation and source code of BRIN index to understand its implementation.
But later I found out that it is unlikely to implement page level or tuple level predicate locking in BRIN index.
In this week, I also fixed a small issue and updated my previous patch for gin index. Currently, I am working on
In this week, I also fixed a small issue and updated my previous patch for gin index. Currently, I am working on
sp-gist index.
Regards,
On Tue, Jul 18, 2017 at 10:36 AM, Shubham Barai <shubhambaraiss@gmail.com> wrote:
During this week, I read documentation and source code of BRIN index to understand its implementation.
But later I found out that it is unlikely to implement page level or tuple level predicate locking in BRIN index.
In this week, I also fixed a small issue and updated my previous patch for gin index. Currently, I am working onsp-gist index.
It's a shame that nobody seems to be answering emails like this, but you also haven't provided much detail here - e.g. *why* is BRIN unlikely to work out well? I think I know the answer, but it'd be good to spell out your thoughts on the subject, I think.
Hi Robert,I had detailed discussion about this with my mentor. Sorry, I didn't share details on hackers list.
on only some and not all internal pages or leaf pages. So, here we have scope to reduce false positives.
In BRIN index, each tuple stores summarizing values in the consecutive group of heap pages.
So initially I thought we could implement tuple level predicate locking in BRIN. But, here we scan
the whole index which forces us to acquire predicate lock on all tuples. Acquiring predicate lock on alltuples will be no different than a relation level predicate lock.
On 20 July 2017 at 21:18, Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Jul 18, 2017 at 10:36 AM, Shubham Barai <shubhambaraiss@gmail.com> wrote:During this week, I read documentation and source code of BRIN index to understand its implementation.
But later I found out that it is unlikely to implement page level or tuple level predicate locking in BRIN index.
In this week, I also fixed a small issue and updated my previous patch for gin index. Currently, I am working onsp-gist index.It's a shame that nobody seems to be answering emails like this, but you also haven't provided much detail here - e.g. *why* is BRIN unlikely to work out well? I think I know the answer, but it'd be good to spell out your thoughts on the subject, I think.
On Thu, Jul 20, 2017 at 1:22 PM, Shubham Barai <shubhambaraiss@gmail.com> wrote:
--
I had detailed discussion about this with my mentor. Sorry, I didn't share details on hackers list.
B-tree, gist, spgist, and gin are all tree based indexes where we scan and acquire predicate lockon only some and not all internal pages or leaf pages. So, here we have scope to reduce false positives.In BRIN index, each tuple stores summarizing values in the consecutive group of heap pages.So initially I thought we could implement tuple level predicate locking in BRIN. But, here we scanthe whole index which forces us to acquire predicate lock on all tuples. Acquiring predicate lock on alltuples will be no different than a relation level predicate lock.
Ah, right. Makes sense.