Re: [GSOC][weekly report 9] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

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, in
ReleasePredicateLocks we call ClearOldPredicateLocks()
inconditionally, and there we grab the SerializableFinishedListLock
lock inconditionally for the whole duration of that routine, but
perhaps it would be better to skip the whole ClearOld stuff if the
SerializableFinishedListLock is not available? Find out some way to
ensure that the cleanup 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 being written at about
the same time (or a bit earlier) than the newer ilist.c interface was
being created, which I think had more optimization work thrown in.
Maybe it would be good for predicate.c to ditch use of SHM_QUEUE and
use ilist.c interfaces instead? We could even think about being less
strict about holding exclusive lock on SerializableFinished for the
duration of ClearOldPredicateLocks, i.e. use only a share lock and
only exchange for exclusive if a list modification is needed.

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