Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)
Teodor Sigaev <teodor@sigaev.ru>
From: Teodor Sigaev <teodor@sigaev.ru>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Dmitry Ivanov <d.ivanov@postgrespro.ru>,
Shubham Barai <shubhambaraiss@gmail.com>,
Alexander Korotkov <a.korotkov@postgrespro.ru>,
Andrey Borodin <x4mmm@yandex-team.ru>,
Thomas Munro <thomas.munro@enterprisedb.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>,
Andrew Borodin <amborodin86@gmail.com>, Kevin Grittner <kgrittn@gmail.com>
Date: 2018-03-29T17:07:33Z
Lists: pgsql-hackers
Attachments
- Predicate-Locking-in-gin-index_v12.patch (text/x-patch) patch v12
Alvaro Herrera wrote:
> I don't quite understand the new call in gininsert -- I mean I see that
> it wants to check for conflicts even when fastupdate is set, but why?
If fastupdate is set then we check conflict with whole index, not a particular
pages in it. Predicate lock on penging list pages will be effectively a lock
over index, because every scan will begin from pending list and each insert will
insert into it. I
> Maybe, just maybe, it would be better to add a new flag to the
> GinCheckForSerializableConflictIn function, that's passed differently
> for this one callsite, and then a comment next to it that indicates why
> do we test for fastupdates in one case and not the other case.
> If you don't like this idea, then I think more commentary on why
> fastupdate is not considered in gininsert is warranted.
>
> In startScanEntry, if you "goto restartScanEntry" in the fastupdate
> case, are you trying to acquire the same lock again? Maybe the lock
> acquire should occur before the goto target? (If this doesn't matter for
> some reason, maybe add a comment about it)
Thank you for noticing that, I've completely rework this part. Somehow I
misreaded actual work of GinGetPendingListCleanupSize() :(.
See attached patch
--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/
Commits
-
Re-think predicate locking on GIN indexes.
- 0bef1c0678d9 11.0 landed
-
Predicate locking in GIN index
- 43d1ed60fdd9 11.0 landed