Horton

Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD

Peter Geoghegan <pg@heroku.com>

View thread
From: Peter Geoghegan <pg@heroku.com>
To: Tatsuo Ishii <ishii@postgresql.org>
Cc: andrew@dunslane.net, sfrost@snowman.net, girgen@freebsd.org, pgsql-hackers@postgresql.org, robertmhaas@gmail.com, ftigeot@wolfpond.org
Date: 2014-04-22T01:16:59Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add shared_memory_type GUC.

On Mon, Apr 21, 2014 at 6:08 PM, Tatsuo Ishii <ishii@postgresql.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