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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
