Skip site navigation (1) Skip section navigation (2)

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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>,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-18 02:49:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-advocacypgsql-hackerspgsql-performance
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                        |
>   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                        |
  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 MomjianDate: 2003-02-18 05:15:43
Subject: Re: [HACKERS] WAL replay logic (was Re: Mount options for
Previous:From: Josh BerkusDate: 2003-02-17 20:03:58
Subject: Re: [PERFORM] Good performance?

pgsql-hackers by date

Next:From: Martin MatusiakDate: 2003-02-18 02:52:42
Subject: Re: postgresql and oracle, compatibility assessment
Previous:From: Bruce MomjianDate: 2003-02-18 02:20:40
Subject: Re: Please apply patch

pgsql-advocacy by date

Next:From: Robert TreatDate: 2003-02-18 18:07:07
Subject: Re: uppercase = lowercase
Previous:From: Donald FraserDate: 2003-02-17 21:54:53
Subject: Re: uppercase = lowercase

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group