On Thu, Feb 25, 2016 at 12:57 PM, Mithun Cy <mithun...@enterprisedb.com> wrote: > I have fixed all of the issues reported by regress test. Also now when > backend try to cache the snapshot we also try to store the self-xid and sub > xid, so other backends can use them. > > I also did some read-only perf tests.
I'm not sure what you are doing that keeps breaking threading for Gmail, but this thread is getting split up for me into multiple threads with only a few messages in each. The same seems to be happening in the community archives. Please try to figure out what is causing that and stop doing it. I notice you seem to not to have implemented this suggestion by Andres: http://www.postgresql.org//message-id/20160104085845.m5nrypvmmpea5...@alap3.anarazel.de Also, you should test this on a machine with more than 2 cores. Andres's original test seems to have been on a 4-core system, where this would be more likely to work out. Also, Andres suggested testing this on an 80-20 write mix, where as you tested it on 100% read-only. In that case there is no blocking ProcArrayLock, which reduces the chances that the patch will benefit. I suspect, too, that the chances of this patch working out have probably been reduced by 0e141c0fbb211bdd23783afa731e3eef95c9ad7a, which seems to be targeting mostly the same problem. I mean it's possible that this patch could win even when no ProcArrayLock-related blocking is happening, but the original idea seems to have been that it would help mostly with that case. You could try benchmarking it on the commit just before that one and then on current sources and see if you get the same results on both, or if there was more benefit before that commit. Also, you could consider repeating the LWLOCK_STATS testing that Amit did in his original reply to Andres. That would tell you whether the performance is not increasing because the patch doesn't reduce ProcArrayLock contention, or whether the performance is not increasing because the patch DOES reduce ProcArrayLock contention but then the contention shifts to CLogControlLock or elsewhere. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
