From: | Daniel Kalchev <daniel(at)digsys(dot)bg> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>, pgsql-advocacy(at)postgresql(dot)org |
Subject: | Re: [HACKERS] Changing the default configuration |
Date: | 2003-02-14 07:55:12 |
Message-ID: | 200302140755.h1E7tCY04481@dcave.digsys.bg |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-advocacy pgsql-hackers |
>>>Bruce Momjian said:
>
> 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.
True, but to make reasonably good choice, they will need to base the parameter
selection on some statistics data. Not many people do trough testing before
tuning their system and in many cases, the tests one do rarely resemble the
real-world usage of their database(s).
I agree that pgtune would be wonderful tool in this case, but they first need
to get some idea what parameters should be given to it.
This process if further complicated by the fact that we can tune PostgreSQL on
a per-installation basis, instead of on per-database basis - many of the
parameters, for example FSM and sort memory are database related. We usually
split data into databases to put related data together or data with similar
usage pattern etc.
Daniel
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Kalchev | 2003-02-14 08:00:28 | Re: [HACKERS] Changing the default configuration |
Previous Message | Christopher Kings-Lynne | 2003-02-14 06:12:50 | Offering tuned config files |
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Kalchev | 2003-02-14 08:00:28 | Re: [HACKERS] Changing the default configuration |
Previous Message | Andrew Dunstan | 2003-02-14 07:35:03 | Re: location of the configuration files |