Re: [HACKERS] GSoC 2017: weekly progress reports (week 7)
От | Shubham Barai |
---|---|
Тема | Re: [HACKERS] GSoC 2017: weekly progress reports (week 7) |
Дата | |
Msg-id | CALxAEPujPA4iMas2g==Wc6XBqq2Ch+=VqnY7L99TQq8sxrGQQA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] GSoC 2017: weekly progress reports (week 7) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] GSoC 2017: weekly progress reports (week 7)
|
Список | pgsql-hackers |

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.
В списке pgsql-hackers по дате отправления: