On Sat, Jul 13, 2013 at 1:47 AM, Jeff Janes <jeff.janes@xxxxxxxxx> wrote: > But I also tried it with 4 pgbench clients, and ran into a collapse of > the performance, TPS dropping down to ~8 TPS. It is too variable to > figure out how reliable the speed-up with this patch is, so far. > Apparently they are all fighting over the spinlock on the > ProcArrayLock. > > This is a single quad core, "Intel(R) Xeon(R) CPU X3210 @ 2.13GHz" > > So I agree with (3) above, about not checking > TransactionIdIsInProgress repeatedly. Or could we change the order of > operations so that TransactionIdIsInProgress is checked only after > XidInMVCCSnapshot? I haven't checked the patch in detail, but it sounds like my proposal for CSN based snapshots[1] could help here. Using it TransactionIdIsInProgress can be done completely lock-free. It would include a direct dense array lookup, read barrier and a check of the dense/sparse horizon, and if necessary a binary search in the sparse array and another read barrier and check for sparse array version counter. I plan to start working on the patch next week. I hope to have a first cut available for CF2. [1] http://www.postgresql.org/message-id/CA+CSw_tEpJ=md1zgxPkjH6CWDnTDft4gBi=+P9SnoC+Wy3pKdA@xxxxxxxxxxxxxx Regards, Ants Aasma -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
