Received: from localhost (unknown [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 0B68A9F9A5B for ; Tue, 11 Sep 2007 08:04:49 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 52534-01 for ; Tue, 11 Sep 2007 08:04:44 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from oxford.xeocode.com (unknown [62.232.55.118]) by postgresql.org (Postfix) with ESMTP id D617A9F9A52 for ; Tue, 11 Sep 2007 08:04:14 -0300 (ADT) Received: from localhost ([127.0.0.1] helo=oxford.xeocode.com) by oxford.xeocode.com with esmtp (Exim 4.67) (envelope-from ) id 1IV3XM-0001O0-Hd; Tue, 11 Sep 2007 12:04:08 +0100 To: "Tom Lane" Cc: Subject: Re: WIP patch for latestCompletedXid method of computing snapshot xmax In-Reply-To: <4084.1189218343@sss.pgh.pa.us> (Tom Lane's message of "Fri\, 07 Sep 2007 22\:25\:43 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+mail01.enterprisedb.com:INBOX" 36653) References: <3018.1189214811@sss.pgh.pa.us> <878x7i0vx1.fsf@oxford.xeocode.com> <4084.1189218343@sss.pgh.pa.us> From: Gregory Stark Organization: EnterpriseDB Date: Tue, 11 Sep 2007 12:04:08 +0100 Message-ID: <878x7dzcnr.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200709/184 X-Sequence-Number: 3726 "Tom Lane" writes: > Gregory Stark writes: >> "Tom Lane" 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