Re: Performance Farm Release

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Scott I(dot) Luxenberg" <Scott(dot)Luxenberg(at)noblis(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Performance Farm Release
Date: 2010-08-25 16:57:56
Message-ID: 20100825165756.GE26232@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Kevin Grittner (Kevin(dot)Grittner(at)wicourts(dot)gov) wrote:
> I actually understood that part, but was already wondering if it
> could be bent to slightly different purposes. It seems as though
> there would be value to using it to evaluate the performance impact
> of a proposed patch, at least on a limited basis, *before* a commit.
> If there's not an immediately obvious way to put it to that
> alternative use, that's OK; I just thought I'd ask.

You can certainly run it yourself locally w/o setting it up to report
back to the build or performance farm.. So, yes, you can, you'll just
have to look through the outputs yourself and it won't necessairly make
much sense unless you've been doing those runs for a period of time to
get a feel for how volatile the speed is on your system..

I guess one issue would be figuring out how to inject your patch into
the process.. If you have it committed to a git instance somewhere, you
could tell it to pull from that after running on the main PG w/o the
patch..

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2010-08-25 17:02:48 Re: Deadlock bug
Previous Message Robert Haas 2010-08-25 16:35:53 Re: git: uh-oh