Re: "--tuning" compile and runtime option (?) - Mailing list pgsql-hackers

From August Zajonc
Subject Re: "--tuning" compile and runtime option (?)
Date
Msg-id 9atn7p$hgp$1@news.tht.net
Whole thread Raw
In response to Re: "--tuning" compile and runtime option (?)  (Bruce Momjian <pgman@candle.pha.pa.us>)
List 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 by date:

Previous
From: "Homayoun Yousefi'zadeh"
Date:
Subject: Re: [GENERAL] JDBC and Perl compiling problems w/ postgresql-7.1rc4
Next
From: Doug McNaught
Date:
Subject: Re: Re: [GENERAL] JDBC and Perl compiling problems w/ postgresql-7.1rc4