Re: [HACKERS] Changing the default configuration (was Re:

From: Kevin Brown <kevin(at)sysexperts(dot)com>
To: PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>, pgsql-advocacy(at)postgresql(dot)org
Subject: Re: [HACKERS] Changing the default configuration (was Re:
Date: 2003-02-14 05:06:00
Message-ID: 20030214050600.GP1833@filer
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers pgsql-performance

Bruce Momjian wrote:
> 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.

If you're going to do that, then you may as well make the defaults
something that will perform reasonably well under the widest
circumstances possible and let the postmaster fail when it can't
acquire the resources those defaults demand.

What I'd do is go ahead and make the defaults something reasonable,
and if the postmaster can't allocate, say, enough shared memory pages,
then it should issue an error message saying not only that it wasn't
able to allocate enough shared memory, but also which parameter to
change and (if it's not too much trouble to implement) what it can be
changed to in order to get past that part of the initialization (this
means that the postmaster has to figure out how much shared memory it
can actually allocate, via a binary search allocate/free method). It
should also warn that by lowering the value, the resulting performance
may be much less than satisfactory, and that the alternative (to
increase SHMMAX, in this example) should be used if good performance
is desired.

That way, someone whose only concern is to make it work will be able
to do so without having to do a lot of experimentation, and will get
plenty of warning that the result isn't likely to work very well.

And we end up getting better benchmarks in the cases where people
don't have to touch the default config. :-)

--
Kevin Brown kevin(at)sysexperts(dot)com

In response to

Browse pgsql-advocacy by date

  From Date Subject
Next Message Kevin Brown 2003-02-14 05:31:24 Tuning scenarios (was Changing the default configuration)
Previous Message Sailesh Krishnamurthy 2003-02-14 04:29:27 PG_TEMP_FILES_DIR

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Brown 2003-02-14 05:31:24 Tuning scenarios (was Changing the default configuration)
Previous Message Sailesh Krishnamurthy 2003-02-14 04:29:27 PG_TEMP_FILES_DIR

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Brown 2003-02-14 05:31:24 Tuning scenarios (was Changing the default configuration)
Previous Message Tom Lane 2003-02-14 04:23:44 Re: [HACKERS] More benchmarking of wal_buffers