> Mengxing Liu wrote: >> The CPU utilization of CheckForSerializableConflictOut/In is >> 0.71%/0.69%.
How many cores were on the system used for this test? The paper specifically said that they didn't see performance degradation on the PostgreSQL implementation until 32 concurrent connections with 24 or more cores. The goal here is to fix *scaling* problems. Be sure you are testing at an appropriate scale. (The more sockets, cores, and clients, the better, I think.) On Fri, Jun 2, 2017 at 10:08 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Kevin mentioned during PGCon that there's a paper by some group in > Sydney that developed a benchmark on which this scalability > problem showed up very prominently. https://pdfs.semanticscholar.org/6c4a/e427e6f392b7dec782b7a60516f0283af1f5.pdf "[...] we see a much better scalability of pgSSI than the corresponding implementations on InnoDB. Still, the overhead of pgSSI versus standard SI increases significantly with higher MPL than one would normally expect, reaching around 50% with MPL 128." "Our profiling showed that PostgreSQL spend 2.3% of the overall runtime in traversing these list, plus 10% of its runtime waiting on the corresponding kernel mutexes." If you cannot duplicate their results, you might want to contact the authors for more details on their testing methodology. Note that the locking around access to the list is likely to be a bigger problem than the actual walking and manipulation of the list itself. -- Kevin Grittner VMware vCenter Server https://www.vmware.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
