* 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
In response to
pgsql-hackers by date
|Next:||From: Josh Berkus||Date: 2010-08-25 17:02:48|
|Subject: Re: Deadlock bug|
|Previous:||From: Robert Haas||Date: 2010-08-25 16:35:53|
|Subject: Re: git: uh-oh|