> > # 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])
