Re: Moving postgresql.conf tunables into 2003...

From: Chris Travers <chris(at)travelamericas(dot)com>
To: Matthew Nuzum <cobalt(at)bearfruit(dot)org>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Moving postgresql.conf tunables into 2003...
Date: 2003-07-07 17:08:50
Message-ID: 3F09A922.2050409@travelamericas.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message scott.marlowe 2003-07-07 17:35:24 Re: PostgreSQL vs. MySQL
Previous Message Richard Huxton 2003-07-07 14:40:30 Re: Optimizer differences between 7.2 and 7.3