Very nice, but the #1 problem remains: discoverability. Say you have a IO intensive database, with about 6000 new insertions per seconds, and every 20 minutes

Very nice, but the #1 problem remains: discoverability. Say you have a IO intensive database, with about 6000 new insertions per seconds, and every 20 minutes a few reads to use that data for analytics. Which parameters should you tweak? Personally, in a situation like that I first focus on the filesystem, to have write cache (xfs_syncd_centisecs etc). Then I analyze the queries and work mostly on RAM assignation. For the postgresql.conf, I use recipes that build based on my experience, derived from A/B testing a set of individual modifications. However it remains premature optimization. Only benchmarks can say for sure. So when I feel fancy, I set aside a few days for tests and do a dense exploration of the parameter space for what I think will matter. Yet this remains constrained by discoverability, i.e. by what I think will matter: if I don't know a parameter may matter, it will not be explored in the test set to avoid the curse of dimensionality. TLDR: This website is nice, but could benefit from a few "typical scenarios" to know at least which knobs to try to tweak, along with some methodology for tweaking (ex: filesystem first)