Re: Changing the default configuration (was Re: [pgsql-advocacy]

From: Tilo Schwarz <mail(at)tilo-schwarz(dot)de>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Changing the default configuration (was Re: [pgsql-advocacy]
Date: 2003-02-14 21:55:51
Message-ID: 200302142255.51683.mail@tilo-schwarz.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers pgsql-performance

Bruce Momjian writes:
> Tom Lane wrote:
> > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > So, my idea is to add a message at the end of initdb that states people
> > > should run the pgtune script before running a production server.
> >
> > Do people read what initdb has to say?
> >
> > IIRC, the RPM install scripts hide initdb's output from the user
> > entirely. I wouldn't put much faith in such a message as having any
> > real effect on people...
>
> Yes, that is a problem. We could show something in the server logs if
> pg_tune hasn't been run. Not sure what else we can do, but it would
> give folks a one-stop thing to run to deal with performance
> configuration.
>
> We could prevent the postmaster from starting unless they run pg_tune or
> if they have modified postgresql.conf from the default. Of course,
> that's pretty drastic.

I don't think, that's drastic, if it's done in a user friendy way ;-):

I work with Postgresql for half a year now (and like it very much), but I must
admit, that it takes time to understand the various tuning parameters (what
is not surprising, because you need understand to a certain degree, what's
going on under the hood). Now think of the following reasoning:

- If the resouces of a system (like shared mem, max open files etc.) are not
known, it's pretty difficult to set good default values. That's why it is so
difficult to ship Postgresql with a postgresql.conf file which works nicely
on all systems on this planet.
- On the other hand, if the resouces of a system _are_ known, I bet the people
on this list can set much better default values than any newbie or a static
out-of-the-box postgresql.conf.

Thus the know how which is somehow in the heads of the gurus should be
condensed into a tune program which can be run on a system to detect the
system resources and which dumps a reasonable postgresql.conf. Those defaults
won't be perfect (because the application is not known yet) but much better
than the newbie or out-of-the-box settings.

If the tune program detects, that the system resouces are so limited, that it
makes basically no sense to run Postgresql there, it tells the user what the
options are: Increase the system resources (and how to do it if possible) or
"downtune" the "least reasonable" postgresql.conf file by hand. Given the
resources of average systems today, the chances are much higher, that users
leave Postgresql because "it's slower than other databases" than that they
get upset, because it doesn't start right away the first time.

Now how to make sure, the tune program gets run before postmaster starts the
first time? Prevent postmaster from starting, unless the tune program was run
and fail with a clear error message. The message should state, that the tune
program needs to be run first, why it needs to be run first and the command
line showing how to do that.

If I think back, I would have been happy to see such a message, you just copy
and paste the command to your shell, run the command and a few seconds later
you can restart postmaster with resonable settings. And the big distributors
have their own scipts anyway, so they can put it just before initdb.

Regards,

Tilo

In response to

Browse pgsql-advocacy by date

  From Date Subject
Next Message Bruce Momjian 2003-02-15 00:24:12 Re: [HACKERS] Linux.conf.au 2003 Report
Previous Message Josh Berkus 2003-02-14 18:10:00 Re: Tuning scenarios (was Changing the default configuration)

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-02-14 22:17:22 Re: location of the configuration files
Previous Message Tom Lane 2003-02-14 21:51:14 Re: stats_command_string default?

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2003-02-14 23:19:17 Re: performace problem after VACUUM ANALYZE
Previous Message ShengQiang Shu 2003-02-14 21:04:05 Re: [Gmod-schema] Re: performace problem after VACUUM ANALYZE