Message-ID: <458178CE.7020003@zeut.net>
Date: Thu, 14 Dec 2006 11:16:14 -0500
From: Matthew O'Connor <matthew@zeut.net>
User-Agent: Thunderbird 2.0a1 (Windows/20060724)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: "Joshua D. Drake" <jd@commandprompt.com>, 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
References: <200612140104.kBE14Dx09695@momjian.us>
	<200612131836.25713.josh@agliodbs.com>
	<1166065359.6494.16.camel@localhost.localdomain>
	<15642.1166075096@sss.pgh.pa.us>
In-Reply-To: <15642.1166075096@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:
> "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?

What is to stop us from running the new pgbench against older versions 
of PGSQL?  Any stats taken from a run of pgbench a long time ago 
probably aren't relevant against a modern test anyway as the underlying 
hardware and OS are likely to have changed or been updated.