Skip site navigation (1) Skip section navigation (2)

Re: shared_buffers advice

From: Dimitri Fontaine <dfontaine(at)hi-media(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pierre C <lists(at)peufeu(dot)com>, Dave Crooke <dcrooke(at)gmail(dot)com>, Paul McGarry <paul(at)paulmcgarry(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: shared_buffers advice
Date: 2010-03-19 09:30:55
Message-ID: 8739zwwtdc.fsf@hi-media-techno.com (view raw or flat)
Thread:
Lists: pgsql-performance
Greg Smith <greg(at)2ndquadrant(dot)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

In response to

pgsql-performance by date

Next:From: CorinDate: 2010-03-19 12:26:35
Subject: too complex query plan for not exists query and multicolumn indexes
Previous:From: Dimitri FontaineDate: 2010-03-19 09:04:00
Subject: Re: mysql to postgresql, performance questions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group