From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Shubham Barai <shubhambaraiss(at)gmail(dot)com> |
Cc: | Andrew Borodin <amborodin86(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: GSoC 2017: weekly progress reports (week 7) |
Date: | 2017-07-20 17:39:22 |
Message-ID: | CA+TgmoYhhHPPxrpRWrSbfjN2URVMiQtOYqxOoN7-=N9j0ts8qg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 20, 2017 at 1:22 PM, Shubham Barai <shubhambaraiss(at)gmail(dot)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 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-07-20 17:59:00 | Re: Increase Vacuum ring buffer. |
Previous Message | Robert Haas | 2017-07-20 17:38:22 | Re: WIP Patch: Precalculate stable functions, infrastructure v1 |