Re: [HACKERS] Changing the default configuration

To auto-tune, you would need to monitor swap usage and other stuff that
may vary too much based on load from other systems. Only the admin
knows how to answer some of those questions.

---------------------------------------------------------------------------

Jason Hihn wrote:
> Pardon my ignorance, but there's no way to auto-tune? Ship it with a thread
> that gathers statistics and periodically re-tunes the database parameters.
> Of course, be able to turn it off. People that actually take the time to run
> tune manually will turn it off as to not have the overhead or interruption.
> Those that don't care about pg_tune shouldn't care about having a thread
> around retuning. Those that will care will tune manually.
>
>
>
> -----Original Message-----
> From: pgsql-advocacy-owner(at)postgresql(dot)org
> [mailto:pgsql-advocacy-owner(at)postgresql(dot)org]On Behalf Of Bruce Momjian
> Sent: Thursday, February 13, 2003 2:22 PM
> To: Daniel Kalchev
> Cc: PostgresSQL Hackers Mailing List; pgsql-advocacy(at)postgresql(dot)org
> Subject: Re: [pgsql-advocacy] [HACKERS] Changing the default
> configuration
>
>
>
> I imagined they could run pgtune anytime after install to update those
> performance parameters. It gives them a one-stop location to at least
> do minimal tuning, and as their load changes, they can run it again.
>
> ---------------------------------------------------------------------------
>
> Daniel Kalchev wrote:
> > >>>Bruce Momjian said:
> > [...]
> > > 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.
> >
> > Bruce, this is an very good idea and such tool would simplify setup for
> the
> > me-too type of DBA - we should definitely try to attract them.
> >
> > However, how could one possibly answer the above question, if they setup
> their
> > database for the first time?
> >
> > What is more, these settings are on a per-installation, not per-database -
> > which means, that if you have several small, but active databases and one
> > large database the requirements will be very different.
> >
> > Nobody likes answering such questions when installing new software. You
> might
> > enjoy it the first few times, but then learn the 'answers' and don't even
> > think what the question is. (we all know the answer :)
> >
> > Perhaps indeed a better idea is to have PostgreSQL itself collect usage
> > statistics, and from time to time print 'suggestions' to the log file
> (best in
> > my opinion), or have these available via some query. These suggestions
> should
> > best reflect the of course require minimal intervention to the database
> > system, such as restart etc.
> >
> >
> > Daniel
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: Have you searched our list archives?
> >
> > http://archives.postgresql.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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
>

--
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