-----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@nasby.net
> 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-----
