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...  ("Jim C. Nasby" <jim@nasby.net>)
Список 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 по дате отправления:

Предыдущее
От: "scott.marlowe"
Дата:
Сообщение: Re: PostgreSQL vs. MySQL
Следующее
От: "scott.marlowe"
Дата:
Сообщение: Re: [pgsql-advocacy] About the default performance