Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Tatsuo Ishii <ishii(at)postgresql(dot)org>
Cc: andrew(at)dunslane(dot)net, sfrost(at)snowman(dot)net, girgen(at)freebsd(dot)org, pgsql-hackers(at)postgresql(dot)org, robertmhaas(at)gmail(dot)com, ftigeot(at)wolfpond(dot)org
Subject: Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD
Date: 2014-04-22 01:16:59
Message-ID: CAM3SWZSp95hxB3+t0OyNBebxxuSLxffiau-gu+hO_XgO1PhqjQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Apr 21, 2014 at 6:08 PM, Tatsuo Ishii <ishii(at)postgresql(dot)org> wrote:
>> What we would need is a way to graph the results - that's something
>> beyond my very rudimentary expertise in web programming. If anyone
>> feels like collaborating I'd be glad to hear from them (The web site
>> is programmed in perl + TemplateToolkit, but even that's not
>> immutable. I'm open to using, say, node.js plus one of its templating
>> engines.
>
> gnuplot? (the graph I attached was created by gnuplt).

That's all pgbench-tools itself uses.

The problem with a performance farm is that it's relatively hard to
donate a performance farm member. It more or less requires expensive
hardware, and a large amount of rigor in testing and normalizing
various aspects of the environment that might otherwise add noise.
Then again, it might only take 2 or 3 servers to make a huge
difference. There are a number of different things that would be
immediately compelling to target with that kind of thing, so the first
step is non-obvious too.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2014-04-22 01:19:22 Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD
Previous Message Tom Lane 2014-04-22 01:12:38 Re: Clock sweep not caching enough B-Tree leaf pages?