|From:||Teodor Sigaev <teodor(at)sigaev(dot)ru>|
|To:||Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>|
|Cc:||Dmitry Ivanov <d(dot)ivanov(at)postgrespro(dot)ru>, Shubham Barai <shubhambaraiss(at)gmail(dot)com>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Andrew Borodin <amborodin86(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)gmail(dot)com>|
|Subject:||Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)|
|Views:||Raw Message | Whole Thread | Download mbox|
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(at)sigaev(dot)ru
|Next Message||Alvaro Herrera||2018-03-29 17:24:46||Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)|
|Previous Message||Alexander Korotkov||2018-03-29 13:10:24||Re: [HACKERS] GSoC 2017: weekly progress reports (week 6)|
|Next Message||Tom Lane||2018-03-29 17:09:48||Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently|
|Previous Message||Tomas Vondra||2018-03-29 16:55:45||Re: [HACKERS] path toward faster partition pruning|