On Mar 27, 2011, at 3:20 PM, Greg Smith wrote:
> I just dusted off this code and brought it back to current again. Basically
> a lot of reformatting the new performance farm parts to minimize their diff.
> Once that was done, all of the other buildfarm client updates since then
> applied clea
I just dusted off this code and brought it back to current again.
Basically a lot of reformatting the new performance farm parts to
minimize their diff. Once that was done, all of the other buildfarm
client updates since then applied cleanly.
The result is now sitting as a fork of Andrew's c
On 08/31/2010 03:28 AM, Greg Smith wrote:
1) Nail down what subset of the information gathered locally should be
uploaded to the buildfarm master server. Probably just the same
columns of data already being saved for each test, but perhaps with
some extra metadata. The local animal will a
On Tue, 2010-08-31 at 03:28 -0400, Greg Smith wrote:
> 4) Merge the perfarm fork changes into the mainline buildfarm code. I
> expect continued bitrot of this code as changes are made to the regular
> buildfarm client, so it might be worth considering that sooner rather
> than later.
As Andre
Stephen Frost wrote:
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
Kevin Grittner 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
Eventu
: Luxenberg, Scott I.
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Performance Farm Release
(resending as I also accidentally CC'd pgsql-hackers-owner, not the
list)
On 25/08/10 02:25, Luxenberg, Scott I. wrote:
> This is just my email to notify you all that the project I've been
(resending as I also accidentally CC'd pgsql-hackers-owner, not the list)
On 25/08/10 02:25, Luxenberg, Scott I. wrote:
This is just my email to notify you all that the project I've been
working on with Stephen, the PostgreSQL Performance Farm, has been
released. As of now, it only supports 9.0,
* Kevin Grittner (kevin.gritt...@wicourts.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 lim
>Stephen Frost wrote:
> The goal is to have this running in a similar manner as the build
> farm to identify when a patch has an impact on performance (good
> or bad). Hackers would then be able to view performance farm
> reports similar to viewing build farm reports. Not sure if we'd
> have ale
Kevin,
* Kevin Grittner (kevin.gritt...@wicourts.gov) wrote:
> Would this project be useful for someone trying to assess the
> performance impact of a proposed patch (at least on the developer's
> machine)? What would someone do to use it in this way?
The goal is to have this running in a simila
[resending after noticing that "reply all" resulted in sending to
pgsql-hackers-owner rather than pgsql-hackers]
"Luxenberg, Scott I." wrote:
> This is just my email to notify you all that the project I've been
> working on with Stephen, the PostgreSQL Performance Farm, has been
> released. As
Hey all,
This is just my email to notify you all that the project I've been
working on with Stephen, the PostgreSQL Performance Farm, has been
released. As of now, it only supports 9.0, due to the use of workers.
More details can be found in the readme. The Git repository is located
here: http:
13 matches
Mail list logo
