Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
Cc: Teodor Sigaev <teodor(at)sigaev(dot)ru>, Shubham Barai <shubhambaraiss(at)gmail(dot)com>, Andrew Borodin <amborodin86(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Kevin Grittner <kgrittn(at)gmail(dot)com>
Subject: Re: [HACKERS] GSoC 2017 : Patch for predicate locking in Gist index
Date: 2018-03-27 08:45:32
Message-ID: CAPpHfdsJ9JfgDgTKzN7s-Qt84jYrAGHidTVMcFFh6t+1AS13_Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi!

On Tue, Mar 27, 2018 at 11:16 AM, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
wrote:

> > 27 марта 2018 г., в 12:53, Teodor Sigaev <teodor(at)sigaev(dot)ru> написал(а):
> >
> > I have a question: why do not CheckForSerializableConflictIn() move
> into begining of gistplacetopage()? Seems, it is the single function which
> actually changes page and all predicate locking stuff will be placed in
> single function...
>
> gistplacetopage() is called from
> 1. Buffered build - probably harmless
>

Yes, harmless, but useless.

> 2. Finish split - i'm not sure about this. It seems to me that it is
> necessary... then your version is correct.
>

Yes, it's necessary, because GiST scan can end up on non-leaf page. So,
scan and modify of same non-leaf page should conflict.

Checking for serializable conflicts from buffering build seems useless
overhead. gistplacetopage()
is called from only two places: gistinserttuples()
and gistbufferinginserttuples(). In order to evade
useless overhead for buffering build, I've moved
CheckForSerializableConflictIn() into gistinserttuples().

Also, I find that we call PredicateLockPageSplit() for every page produced
by split including
original. That also seems to cause extra overhead. This is why I've moved
PredicateLockPageSplit() into loop where we do assign new buffers.

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

Attachment Content-Type Size
Predicate-Locking-in-gist-index_v11.patch application/octet-stream 31.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2018-03-27 08:55:45 Re: [HACKERS] GUC for cleanup indexes threshold.
Previous Message konstantin knizhnik 2018-03-27 08:31:05 Re: Index scan prefetch?