From: Dimitri Fontaine <dfontaine@hi-media.com>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Greg Stark <gsstark@mit.edu>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Pierre C <lists@peufeu.com>
Cc: Dave Crooke <dcrooke@gmail.com>
Cc: Paul McGarry <paul@paulmcgarry.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: shared_buffers advice
Date: Fri, 19 Mar 2010 10:30:55 +0100
Message-ID: <8739zwwtdc.fsf@hi-media-techno.com> (raw)
In-Reply-To: <4BA243D3.50708@2ndquadrant.com>
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: dfontaine@hi-media.com, greg@2ndquadrant.com, alvherre@commandprompt.com, gsstark@mit.edu, tgl@sss.pgh.pa.us, lists@peufeu.com, dcrooke@gmail.com, paul@paulmcgarry.com
Subject: Re: shared_buffers advice
In-Reply-To: <8739zwwtdc.fsf@hi-media-techno.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox