Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id A371B9FA363 for ; Thu, 14 Dec 2006 02:11:28 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-new, port 10024) with ESMTP id 37400-07 for ; Thu, 14 Dec 2006 02:11:22 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from proton.planetargon.com (unknown [198.145.37.35]) by postgresql.org (Postfix) with ESMTP id 54DF39F9F08 for ; Thu, 14 Dec 2006 02:11:23 -0400 (AST) Received: from [172.16.1.106] (unknown [61.197.227.146]) by proton.planetargon.com (Postfix) with ESMTP id A4D37855AFD; Wed, 13 Dec 2006 22:11:18 -0800 (PST) In-Reply-To: <15642.1166075096@sss.pgh.pa.us> References: <200612140104.kBE14Dx09695@momjian.us> <200612131836.25713.josh@agliodbs.com> <1166065359.6494.16.camel@localhost.localdomain> <15642.1166075096@sss.pgh.pa.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <274FEBE6-C248-482C-AC27-A0369EC9812C@seespotcode.net> Cc: "Joshua D. Drake" , Josh Berkus , pgsql-performance@postgresql.org, Bruce Momjian , Alvaro Herrera , Alexander Staubo , Michael Stone Content-Transfer-Encoding: 7bit From: Michael Glaesemann Subject: Re: New to PostgreSQL, performance considerations Date: Thu, 14 Dec 2006 15:11:11 +0900 To: Tom Lane X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/358 X-Sequence-Number: 22414 On Dec 14, 2006, at 14:44 , Tom Lane wrote: > The pgbench app itself becomes the bottleneck at high transaction > rates. Awhile back I rewrote it to improve its ability to issue > commands concurrently, but then desisted from submitting the > changes --- if we change the app like that, future numbers would > be incomparable to past ones, which sort of defeats the purpose of a > benchmark no? At the same time, if the current pgbench isn't the tool we want to use, is this kind of backward comparison going to hinder any move to improve it? It sounds like there's quite a bit of room for improvement in pg_bench, and in my opinion we should move forward to make an improved tool, one that measures what we want to measure. And while comparison with past results might not be possible, there remains the possibility of rerunning the improved pgbench on previous systems, I should think. Michael Glaesemann grzm seespotcode net