Re: WIP patch for latestCompletedXid method of computing snapshot xmax - Mailing list pgsql-patches

From Gregory Stark
Subject Re: WIP patch for latestCompletedXid method of computing snapshot xmax
Date
Msg-id 878x7dzcnr.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: WIP patch for latestCompletedXid method of computing snapshot xmax  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Gregory Stark
Date:
Subject: Re: Yet more tsearch refactoring
Next
From: "Pavan Deolasee"
Date:
Subject: Re: HOT patch - version 15