Received: from localhost (maia-5.hub.org [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id B50129F9F08
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 14 Dec 2006 01:50:03 -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 35549-04-5
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 14 Dec 2006 01:49:51 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id 051779FB287
	for <pgsql-performance@postgresql.org>;
	Thu, 14 Dec 2006 01:45:02 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id kBE5iutw015643;
	Thu, 14 Dec 2006 00:44:56 -0500 (EST)
To: "Joshua D. Drake" <jd@commandprompt.com>
cc: Josh Berkus <josh@agliodbs.com>, pgsql-performance@postgresql.org,
	Bruce Momjian <bruce@momjian.us>,
	Alvaro Herrera <alvherre@commandprompt.com>,
	Alexander Staubo <alex@purefiction.net>,
	Michael Stone <mstone+postgres@mathom.us>
Subject: Re: New to PostgreSQL, performance considerations 
In-reply-to: <1166065359.6494.16.camel@localhost.localdomain> 
References: <200612140104.kBE14Dx09695@momjian.us>
	<200612131836.25713.josh@agliodbs.com>
	<1166065359.6494.16.camel@localhost.localdomain>
Comments: In-reply-to "Joshua D. Drake" <jd@commandprompt.com>
	message dated "Wed, 13 Dec 2006 19:02:39 -0800"
Date: Thu, 14 Dec 2006 00:44:56 -0500
Message-ID: <15642.1166075096@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200612/357
X-Sequence-Number: 22413

"Joshua D. Drake" <jd@commandprompt.com> writes:
> On Wed, 2006-12-13 at 18:36 -0800, Josh Berkus wrote:
>> Mostly, though, pgbench just gives the I/O system a workout.  It's not a 
>> really good general workload.

> It also will not utilize all cpus on a many cpu machine. We recently
> found that the only way to *really* test with pgbench was to actually
> run 4+ copies of pgbench at the same time.

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?

			regards, tom lane