Re: Perfomance degradation 9.3 (vs 9.2) for FreeBSD
Andrew Dunstan <andrew@dunslane.net>
From: Andrew Dunstan <andrew@dunslane.net>
To: Peter Geoghegan <pg@heroku.com>
Cc: Tatsuo Ishii <ishii@postgresql.org>, sfrost@snowman.net,
girgen@freebsd.org, pgsql-hackers@postgresql.org, robertmhaas@gmail.com,
ftigeot@wolfpond.org
Date: 2014-04-22T01:19:22Z
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 →
-
Add shared_memory_type GUC.
- f1bebef60ec8 12.0 landed
On 04/21/2014 09:16 PM, Peter Geoghegan wrote: > 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. > If we never start we'll never get there. I can think of several organizations that might be approached to donate hardware. cheers andrew