Re: Moving postgresql.conf tunables into 2003...
От | Chris Travers |
---|---|
Тема | Re: Moving postgresql.conf tunables into 2003... |
Дата | |
Msg-id | 3F09A922.2050409@travelamericas.com обсуждение исходный текст |
Ответ на | Re: Moving postgresql.conf tunables into 2003... ("Matthew Nuzum" <cobalt@bearfruit.org>) |
Ответы |
Re: Moving postgresql.conf tunables into 2003...
|
Список | pgsql-performance |
Matthew Nuzum wrote: >>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. >> >> > >I agree. > >We often seem to forget simple lessons in human nature. Expecting someone >to spend 20 extra seconds to do something is often too much. In many cases, >the only "manual" that a person will see is the .conf files. > > > In my opinion, a serious RDBMS system will *always* require the admin to be doing research in order to learn how to use it effectively. We are not talking about a word processor here. That being said, I think that a good part of the problem is that admins don't know where to look for the appropriate documentation and what is needed. Expecting someone to spend 20 seconds looking for a piece of info is not too bad, but expecting them to spend hours trying to figure out what info is relavent is not going to get us anywhere. For those who have been following the discussion relating to MySQL vs PostgreSQL, I think this is relavent here. MySQL does much of its tuning at compile time, and the MySQL team very carefully controls the build process for the various binary distriutions they offer. If you want to see a real mess, try compiling MySQL from source. Talk about having to read documentation on items which *should* be handled by the configure script. OTOH, PostgreSQL is optomized using configuration files and is tunable on the fly. This is, I think, a better approach but it needs to be better documented. Maybe a "Beginner's guide to database server tuning" or something like that. Secondly, documenting the tuning algorythms well my allow PostgreSQL to automatically tune itself to some extent or for the development of performance tuning tools for the server. This would be a big win for the project. Unfortunately I am not knowledgable on this topic to really do this subject justice. Best Wishes, Chris Travers
В списке pgsql-performance по дате отправления: