From: Dimitri Fontaine <dfontaine@hi-media.com>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, Greg Stark <gsstark@mit.edu>,
	Tom Lane <tgl@sss.pgh.pa.us>, Pierre C <lists@peufeu.com>,
	Dave Crooke <dcrooke@gmail.com>, Paul McGarry <paul@paulmcgarry.com>,
	pgsql-performance@postgresql.org
Subject: Re: shared_buffers advice
Organization: Hi-Media
References: <a056b1d41003101728h2bfe964cg43bf5ef1aabae14d@mail.gmail.com>
	<ca24673e1003152217q117b0fd3q7d2d75ff20185c8b@mail.gmail.com>
	<4B9F3302.4020900@2ndquadrant.com> <op.u9nrbeeteorkce@localhost>
	<8285.1268749832@sss.pgh.pa.us>
	<407d949e1003160753o6e5faa48rabaa42f7548029b7@mail.gmail.com>
	<20100316213054.GG3037@alvh.no-ip.org>
	<4BA01A4C.9090509@2ndquadrant.com>
	<871vfivsfa.fsf@hi-media-techno.com> <4BA243D3.50708@2ndquadrant.com>
User-Mail-Address: dfontaine@hi-media.com
Date: Fri, 19 Mar 2010 10:30:55 +0100
In-Reply-To: <4BA243D3.50708@2ndquadrant.com> (Greg Smith's message of "Thu,
	18 Mar 2010 11:16:35 -0400")
Message-ID: <8739zwwtdc.fsf@hi-media-techno.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Greg Smith <greg@2ndquadrant.com> writes:
> However, that doesn't actually solve any of the problems I was talking about
> though, which is why I'm not even talking about that part.  We need the glue
> to pull out software releases, run whatever testing tool is appropriate, and
> then save the run artifacts in some standardized form so they can be
> referenced with associated build/configuration information to track down a
> regression when it does show up.  Building those boring bits are the real
> issue here; load testing tools are easy to find because those are fun to
> work on.

Oh, ok. I missparsed the previous message. Tsung has a way to monitor OS
level information, and I guess adding the build/configuration would
be... as easy as adding it to pgbench :)

> And as a general commentary on the vision here, tsung will never fit into
> this anyway because "something that can run on the buildfarm machines with
> the software they already have installed" is the primary target.  I don't
> see anything about tsung so interesting that it trumps that priority, even
> though it is an interesting tool.

I though we might talk about a performance farm which would be quite
different, if only because to sustain a high enough client load you
might need more than one injector machine targeting a given server at
once.

But if you target the buildfarm, introducing new dependencies does sound
like a problem (that I can't evaluate the importance of).

Regards,
-- 
dim