From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Greg Smith <gsmith(at)gregsmith(dot)com>, Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, "Decibel!" <decibel(at)decibel(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com> |
Subject: | Re: Overhauling GUCS |
Date: | 2008-06-06 12:39:31 |
Message-ID: | 200806061439.32335.peter_e@gmx.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Am Donnerstag, 5. Juni 2008 schrieb Tom Lane:
> How far could we get with the answers to just three questions:
>
> * How many concurrent queries do you expect to have?
>
> * How much RAM space are you willing to let Postgres use?
>
> * How much "overhead" disk space are you willing to let Postgres use?
This is surely a good start. We could optimize this even more by saying, disk
space is cheap, so let's just use a much higher default setting for
checkpoint_segments. (If PostgreSQL is installed but not actually used, not
all the space is actually going to be used anyway.) Then, increase
max_connections a bit; that should be OK for most users. Then you are left
with the memory settings, and those need kernel tuning in most cases, so any
automation tool loses. Hmm.
From | Date | Subject | |
---|---|---|---|
Next Message | Aidan Van Dyk | 2008-06-06 12:40:40 | Re: Overhauling GUCS |
Previous Message | Peter Eisentraut | 2008-06-06 12:35:00 | Re: Overhauling GUCS |