Re: Performance Farm Release

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Stephen Frost" <sfrost(at)snowman(dot)net>
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:10:36
Message-ID: 4C74FA2C0200002500034B9C@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>Stephen Frost <sfrost(at)snowman(dot)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 we'd
> have alerts or something, but I'd think in alot of cases a given
> hacker would know that they're commiting something performance-
> impacting (or saw someone else commit something that could be) and
> they'd go check out the performance farm reports a few days later
> to determine if there was a change.

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.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-08-25 16:28:20 Re: initdb fails to allocate shared memory
Previous Message Michael Haggerty 2010-08-25 16:02:39 Re: git: uh-oh