Re: GSoC 2017: weekly progress reports (week 6)

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Shubham Barai <shubhambaraiss(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andrew Borodin <amborodin86(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)gmail(dot)com>
Subject: Re: GSoC 2017: weekly progress reports (week 6)
Date: 2017-09-27 21:45:15
Message-ID: CAPpHfdvED_-7KbJp-ei4zRZu1brLgkJt4CA-uxF0iRO9WX2Sqw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-www

Hi!

On Wed, Aug 9, 2017 at 6:30 PM, Shubham Barai <shubhambaraiss(at)gmail(dot)com>
wrote:

> Please find the updated patch for predicate locking in gin index here.
>
> There was a small issue in the previous patch. I didn't consider the case
> where only root page exists in the tree, and there is a predicate lock on
> it,
> and it gets split.
>
> If we treat the original page as a left page and create a new root and
> right
> page, then we just need to copy a predicate lock from the left to the
> right
> page (this is the case in B-tree).
>
> But if we treat the original page as a root and create a new left and right
> page, then we need to copy a predicate lock on both new pages (in the case
> of rum and gin).
>
> link to updated code and tests: https://github.com/
> shubhambaraiss/postgres/commit/6172639a104785f051cb4aa0d511c58f2bae65a6
>

I've assigned to review this patch. First of all I'd like to understand
general idea of this patch.

As I get, you're placing predicate locks to both entry tree leaf pages and
posting tree leaf pages. But, GIN implements so called "fast scan"
technique which allows it to skip some leaf pages of posting tree when
these pages are guaranteed to not contain matching item pointers. Wherein
the particular order of posting list scan and skip depends of their
estimated size (so it's a kind of coincidence).

But thinking about this more generally, I found that proposed locking
scheme is redundant. Currently when entry has posting tree, you're locking
both:
1) entry tree leaf page containing pointer to posting tree,
2) leaf pages of corresponding posting tree.
Therefore conflicting transactions accessing same entry would anyway
conflict while accessing the same entry tree leaf page. So, there is no
necessity to lock posting tree leaf pages at all. Alternatively, if entry
has posting tree, you can skip locking entry tree leaf page and lock
posting tree leaf pages instead.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-09-27 21:51:46 Re: Use of RangeVar for partitioned tables in autovacuum
Previous Message Pavel Stehule 2017-09-27 20:41:52 Re: proposal - Default namespaces for XPath expressions (PostgreSQL 11)

Browse pgsql-www by date

  From Date Subject
Next Message Alexander Korotkov 2017-09-28 10:19:38 Re: GSoC 2017: weekly progress reports (week 6)
Previous Message Michael Paquier 2017-09-26 23:28:27 Re: User-perspective knowledge about wait events