Actually this sounds like a good idea to me.
Type: <popular app #1>, <popular app #2>, OLAP, OLTP?
Server: Small, Regular, Large.
That way one can see a pattern and have a better guess of how to tune
things. My concern is not so much of getting things perfectly right. It's
more like avoiding "terribly wrong" settings e.g. postgresql running many
times slower than it could on a given system.
I mean how would one tune for single user, huge (e.g. stuff >> mem, cache)
aggregating selects vs tuning for many users, lots of updates? How about
tuning for big inserts/COPYs? How should the WAL logs be adjusted if at
all? Would bumping up sort mem help if the stuff you're sorting is a lot
more than the RAM you have?
Link.
At 05:33 PM 6/11/2003 -0400, Matthew Nuzum wrote:
>Some databases (MySQL I think) ship several example configurations sized for
>different installations. The default is very safe, but it's simply a matter
>of choosing between "small.conf", "medium.conf", "big.conf", "huge.conf" and
>copying it over the standard "tiny.conf" file.
>
>Each config file contains comments near the top of the file that specify
>suggested hardware requirements for using it.
>
>Providing a similar series of config files for postgres would probably cut
>the traffic to the performance mailing list significantly and end the need
>for discussions such as this. (not that I mind the discussion)
