People seemed to like the idea:
Add a script to ask system configuration questions and tune
Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Tom Lane writes:
> > > Well, as I commented later in that mail, I feel that 1000 buffers is
> > > a reasonable choice --- but I have to admit that I have no hard data
> > > to back up that feeling.
> > I know you like it in that range, and 4 or 8 MB of buffers by default
> > should not be a problem. But personally I think if the optimal buffer
> > size does not depend on both the physical RAM you want to dedicate to
> > PostgreSQL and the nature and size of the database, then we have achieved
> > a medium revolution in computer science. ;-)
> I have thought about this and I have an idea. Basically, increasing the
> default values may get us closer, but it will discourage some to tweek,
> and it will cause problems with some OS's that have small SysV params.
> 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.
> The pgtune script will basically allow us to query the user, test the OS
> version and perhaps parameters, and modify postgresql.conf with
> reasonable values. I think this is the only way to cleanly get folks
> close to where they should be.
> For example, we can ask them how many rows and tables they will be
> changing, on average, between VACUUM runs. That will allow us set the
> FSM params. We can ask them about using 25% of their RAM for shared
> buffers. If they have other major apps running on the server or have
> small tables, we can make no changes. We can basically ask them
> questions and use that info to set values.
> We can even ask about sort usage maybe and set sort memory. We can even
> control checkpoint_segments this way if they say they will have high
> database write activity and don't worry about disk space usage. We may
> even be able to compute some random page cost estimate.
> Seems a script is going to be the best way to test values and assist
> folks in making reasonable decisions about each parameter. Of course,
> they can still edit the file, and we can ask them if they want
> assistance to set each parameter or leave it alone.
> I would restrict the script to only deal with tuning values, and tell
> people they still need to review that file for other useful parameters.
> Another option would be to make a big checklist or web page that asks
> such questions and computes proper values, but it seems a script would
> be easiest. We can even support '?' which would explain why the
> question is being ask and how it affects the value.
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
In response to
pgsql-performance by date
|Next:||From: Bruce Momjian||Date: 2003-02-18 05:15:43|
|Subject: Re: [HACKERS] WAL replay logic (was Re: Mount options for|
|Previous:||From: Josh Berkus||Date: 2003-02-17 20:03:58|
|Subject: Re: [PERFORM] Good performance?|
pgsql-hackers by date
|Next:||From: Martin Matusiak||Date: 2003-02-18 02:52:42|
|Subject: Re: postgresql and oracle, compatibility assessment|
|Previous:||From: Bruce Momjian||Date: 2003-02-18 02:20:40|
|Subject: Re: Please apply patch|
pgsql-advocacy by date
|Next:||From: Robert Treat||Date: 2003-02-18 18:07:07|
|Subject: Re: uppercase = lowercase|
|Previous:||From: Donald Fraser||Date: 2003-02-17 21:54:53|
|Subject: Re: uppercase = lowercase|