| From: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | 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>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com> |
| Subject: | Re: Overhauling GUCS |
| Date: | 2008-06-05 19:50:24 |
| Message-ID: | 48484380.1010504@cheapcomplexdevices.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane wrote:
> 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?
+1 to this approach - these are the kinds of questions that
make sense to me when first setting up a new installation.
They sound useful for both large servers and tiny (salesguy
laptop for demos) installations.
> If those aren't enough questions, what else must we ask?
* Perhaps something to guess FSM settings? I think FSM is
tunable I most often get wrong with more painful
consequences (bloat) than other tunables.
My approach is to have cron run database-wide vacuums
even on systems with autovacuum just to see the log
messages about FSM.
* Something to tune vacuum delay? Perhaps:
How much I/O bandwidth can be dedicated to Postgres
background activities?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ron Mayer | 2008-06-05 19:53:55 | Re: Overhauling GUCS |
| Previous Message | Robert Lor | 2008-06-05 19:47:16 | Re: Overhauling GUCS |