Re: "--tuning" compile and runtime option (?)
От | August Zajonc |
---|---|
Тема | Re: "--tuning" compile and runtime option (?) |
Дата | |
Msg-id | 9atn7p$hgp$1@news.tht.net обсуждение исходный текст |
Ответ на | Re: "--tuning" compile and runtime option (?) (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | pgsql-hackers |
I'd be happy to see during initial setup a few questions go by that would size the underlying OS properly as well. We all do the same things with a new system, increase filesystem limits etc... Some of these options (on a dedicated postgresql) are gimme's. Why not do them once upfront, prompt the user (share memory, file handles) are to low, should I increase the limits? I'd love it, and some of the "PostgreSQL doesn't scale even the the load is low" complaints would go away. The hitch I can see is that much will be distribution/platform specific, but those don't change that radically that motivated volunteers couldn't keep pace. August "Bruce Momjian" <pgman@candle.pha.pa.us> wrote in message news:200104091744.NAA12563@candle.pha.pa.us... > OK, what options would you recommend be auto-tuned in each circumstance? > I can imagine open files and maybe sortmemory, but even then, other > backends can affect the proper value. Share memory usually has a kernel > limit which prevents us from auto-tuning that too much. > > -- > Bruce Momjian | http://candle.pha.pa.us > pgman@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster
В списке pgsql-hackers по дате отправления: