> > # The default values for PostgreSQL are extremely conservative and > > # are likely far from ideal for a site's needs. Included in this > > # configuration, however, are _suggested_ values to help aid in > > > # <snip> > > This sort of narrative belongs in the SGML docs, not in a CONF file. > In fact, one could argue that we should take *all* commentary out of > the CONF file in order to force people to read the docs.
The SGML docs aren't in the DBA's face and are way out of the way for DBAs rolling out a new system or who are tuning the system. SGML == Developer, conf == DBA. > Database performance tuning will always be a "black art," as it > necessitates a broad knowledge of PostgreSQL, OS architecture, and > computer hardware. So I doubt that we can post docs that would > allow any 10% time DBA to make PostgreSQL "fly", but hopefully over > the next year we can make enough knowledge public to allow anyone to > make PostgreSQL "sprint". I'm highly resistant to/disappointed in this attitude and firmly believe that there are well understood algorithms that DBAs use to diagnose and solve performance problems. It's only a black art because it hasn't been documented. Performance tuning isn't voodoo, it's adjusting constraints to align with the execution of applications and we know what the applications do, therefore the database can mold to the applications' needs. Some of those parameters are based on hardware constraints and should be pooled and organized as such. random_page_cost == avg cost of a random disk seek/read (eg: disk seek time) == constant integer for a given piece of hardware There are other settings that are RAM based as well, which should be formulaic and derived though a formula hasn't been defined to date. -sc -- Sean Chittenden ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])