Re: In progress INSERT wrecks plans on table
От | Ants Aasma |
---|---|
Тема | Re: In progress INSERT wrecks plans on table |
Дата | |
Msg-id | CA+CSw_suZ2ho9dECXXZoMjQgeXptWS9C1MLbPb_cak0xHKQH3A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: In progress INSERT wrecks plans on table (Jeff Janes <jeff.janes@gmail.com>) |
Список | pgsql-performance |
On Sat, Jul 13, 2013 at 1:47 AM, Jeff Janes <jeff.janes@gmail.com> 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@mail.gmail.com Regards, Ants Aasma -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de
В списке pgsql-performance по дате отправления: