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

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Josh BerkusDate: 2010-08-25 17:02:48
Subject: Re: Deadlock bug
Previous:From: Robert HaasDate: 2010-08-25 16:35:53
Subject: Re: git: uh-oh

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