Skip site navigation (1) Skip section navigation (2)

Re: WIP patch for latestCompletedXid method of computing snapshot xmax

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-patches(at)postgresql(dot)org>
Subject: Re: WIP patch for latestCompletedXid method of computing snapshot xmax
Date: 2007-09-11 11:04:08
Message-ID: 878x7dzcnr.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Gregory Stark <stark(at)enterprisedb(dot)com> writes:
>> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2007-09-11 11:20:19
Subject: Re: Final Thoughts for 8.3 on LWLocking and Scalability
Previous:From: Marko KreenDate: 2007-09-11 10:31:47
Subject: Re: Final Thoughts for 8.3 on LWLocking and Scalability

pgsql-patches by date

Next:From: Simon RiggsDate: 2007-09-11 11:20:19
Subject: Re: Final Thoughts for 8.3 on LWLocking and Scalability
Previous:From: Marko KreenDate: 2007-09-11 10:31:47
Subject: Re: Final Thoughts for 8.3 on LWLocking and Scalability

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group