Re: [HACKERS] GSoC 2017: weekly progress reports (week 7)

[Robert Haas]

On Thu, Jul 20, 2017 at 1:22 PM, Shubham Barai 
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 lock
> 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 all
> tuples will be no different than a relation level predicate lock.
>

Ah, right.  Makes sense.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Re: [HACKERS] GSoC 2017: weekly progress reports (week 7)

[Shubham Barai]

Hi Robert,

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 lock
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 all
tuples will be no different than a relation level predicate lock.


Regards,
Shubham



 Sent with Mailtrack


On 20 July 2017 at 21:18, Robert Haas  wrote:

> On Tue, Jul 18, 2017 at 10:36 AM, Shubham Barai 
> 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 on
>> sp-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.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

Re: [HACKERS] GSoC 2017: weekly progress reports (week 7)

[Robert Haas]

On Tue, Jul 18, 2017 at 10:36 AM, Shubham Barai 
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 on
> sp-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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

[HACKERS] GSoC 2017: weekly progress reports (week 7)

[Shubham Barai]

Project: Explicitly support predicate locks in index AMs besides b-tree

Hi,

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
sp-gist index.


Regards,
Shubham

 Sent with Mailtrack