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
On Mar 27, 2011, at 3:20 PM, Greg Smith g...@2ndquadrant.com 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
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
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 Andrew
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
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
To: 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
working
[resending after noticing that reply all resulted in sending to
pgsql-hackers-owner rather than pgsql-hackers]
Luxenberg, Scott I. scott.luxenb...@noblis.org wrote:
This is just my email to notify you all that the project I've been
working on with Stephen, the PostgreSQL Performance Farm,
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 similar
Stephen Frost sfr...@snowman.net 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
* 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
(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
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:
13 matches
Mail list logo
