-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Only some problems that come to my mind with this: a) Hardware is sometimes changed underhand without telling the customer. Even for server-level hardware. (Been there.) b) Hardware recommendations would get stale quickly. What use is a hardware spec that specifies some versions of Xeons, when the supply dries up. (the example is not contrived, certain versions of PG and Xeons with certain usage patterns don't work that well. google for context switch storms) c) All that is depending upon the PG version too, so with every new version somebody would have to reverify that the recommendations are still valid. (Big example, partitioned tables got way better supported in recent versions. So a setup that anticipated Seqscans over big tables might suddenly perform way better. OTOH, there are some regressions performance wise sometimes) d) And to add insult to this, all that tuning (hardware and software side) is sensitive to your workload. Before you start yelling, well, have you ever rolled back an application version, because you notice what stupidities the developers have added. (And yes you can try to avoid this by adding better staging to your processes, but it's really really hard to setup a staging environment that has the same performance characteristics as production.) So, while it's a nice idea to have a set of recommended hardware setups, I don't see much of a point. What makes a sensible database server is not exactly a secret. Sizing slightly harder. And after that one enters the realm of fine tuning the complete system. That does not end at the socket on port 5432. Andreas Jim Nasby wrote: > On May 4, 2007, at 12:11 PM, Josh Berkus wrote: >> Sebastian, >>> Before inventing a hyper tool, we might consider to provide 3-5 example >>> szenarios for common hardware configurations. This consumes less time >>> and be discussed and defined in a couple of days. This is of course not >>> the correct option for a brandnew 20 spindle Sata 10.000 Raid 10 system >>> but these are probably not the target for default configurations. >> >> That's been suggested a number of times, but some GUCs are really tied >> to the >> *exact* amount of RAM you have available. So I've never seen how >> "example >> configurations" could help. > > Uh... what GUCs are that exacting on the amount of memory? For a decent, > base-line configuration, that is. > -- > Jim Nasby jim@xxxxxxxxx > EnterpriseDB http://enterprisedb.com 512.569.9461 (cell) > > > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGPX5aHJdudm4KnO0RAorYAJ9XymZy+pp1oHEQUu3VGB7G2G2cSgCfeGaU X2bpEq3aM3tzP4MYeR02D6U= =vtPy -----END PGP SIGNATURE-----
