Re: WIP patch for latestCompletedXid method of computing snapshot xmax
От | Gregory Stark |
---|---|
Тема | Re: WIP patch for latestCompletedXid method of computing snapshot xmax |
Дата | |
Msg-id | 878x7dzcnr.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: WIP patch for latestCompletedXid method of computing snapshot xmax (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-patches |
"Tom Lane" <tgl@sss.pgh.pa.us> writes: > Gregory Stark <stark@enterprisedb.com> writes: >> "Tom Lane" <tgl@sss.pgh.pa.us> writes: >>> This patch implements Florian's idea about how to manage snapshot xmax >>> without the ugly and performance-losing tactic of taking XidGenLock and >>> ProcArrayLock at the same time. I had to do a couple of slightly klugy >>> things to get bootstrap and prepared transactions to work, but on the >>> whole it seems at least as clean as the code we have now. Comments? > >> Just that it will be fascinating to see what effects this has on the >> benchmarks. > > Yeah, I was hoping to get some benchmarks before deciding whether it's > worth the risk of pushing this into 8.3. I'm off trying pgbench now, > but if anyone wants to try something more serious like DBT2 ... I ran some DBT2 tests but haven't been able to show any performance effects either in average or worst-case response times. I think that's for a few reasons: 1) This is only a dual-processor machine I'm playing with and we scale well on two processors already. 2) TPC-C doesn't have many read-only transactions 3) The deadlocks I found earlier cause enough noise in the response times to hide any subtler effects. We may have to wait until the next time Sun runs their 1,000-process monster Java benchmark to see if it helps there. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
В списке pgsql-patches по дате отправления: