[HACKERS] Re: [GSOC][weekly report 9] Eliminate O(N^2) scaling fromrw-conflict tracking in serializable transactions - Mailing list pgsql-hackers

From Alvaro Herrera
Subject [HACKERS] Re: [GSOC][weekly report 9] Eliminate O(N^2) scaling fromrw-conflict tracking in serializable transactions
Date
Msg-id 20170807175152.75ebcrnmfbamvsgm@alvherre.pgsql
Whole thread Raw
In response to [HACKERS] [GSOC][weekly report 9] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions  ("Mengxing Liu" <liu-mx15@mails.tsinghua.edu.cn>)
Responses [HACKERS] Re: [GSOC][weekly report 9] Eliminate O(N^2) scaling fromrw-conflict tracking in serializable transactions  ("Mengxing Liu" <liu-mx15@mails.tsinghua.edu.cn>)
Re: [HACKERS] Re: [GSOC][weekly report 9] Eliminate O(N^2) scalingfrom rw-conflict tracking in serializable transactions  (Robert Haas <robertmhaas@gmail.com>)
[HACKERS] Re: [GSOC][weekly report 9] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions  ("Mengxing Liu" <liu-mx15@mails.tsinghua.edu.cn>)
List pgsql-hackers
Mengxing Liu wrote:
> In the last week, I focus on:
> 
> 
> 1) Continuing on optimization of skip list.

Let me state once again that I'm certainly not an
expert in the predicate locks module and that I hope Kevin will chime in
with more useful feedback than mine.

Some random thoughts:

* I wonder why did you settle on a skip list as the best optimization path for this.  Did you consider other data
structures? (We don't seem to have much that would be usable in shared memory, I fear.)
 

* I wonder if a completely different approach to the finished xact maintenance problem would be helpful.  For instance,
inReleasePredicateLocks we call ClearOldPredicateLocks() inconditionally, and there we grab the
SerializableFinishedListLocklock inconditionally for the whole duration of that routine, but perhaps it would be better
toskip the whole ClearOld stuff if the SerializableFinishedListLock is not available?  Find out some way to ensure that
thecleanup is always called later on, but maybe skipping it once in a while improves overall performance.
 

* the whole predicate.c stuff is written using SHM_QUEUE.  I suppose SHM_QUEUE works just fine, but predicate.c was
beingwritten at about the same time (or a bit earlier) than the newer ilist.c interface was being created, which I
thinkhad more optimization work thrown in. Maybe it would be good for predicate.c to ditch use of SHM_QUEUE and use
ilist.cinterfaces instead?  We could even think about being less strict about holding exclusive lock on
SerializableFinishedfor the duration of ClearOldPredicateLocks, i.e. use only a share lock and only exchange for
exclusiveif a list modification is needed.
 

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: "Mengxing Liu"
Date:
Subject: [HACKERS] [GSOC][weekly report 9] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions
Next
From: Andrew Dunstan
Date:
Subject: [HACKERS] Re: [COMMITTERS] pgsql: Record full paths of programs sought by"configure".