Re: "--tuning" compile and runtime option (?)

From: "August Zajonc" <junk-postgre(at)aontic(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: "--tuning" compile and runtime option (?)
Date: 2001-04-10 01:21:57
Message-ID: 9atn7p$hgp$1@news.tht.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)candle(dot)pha(dot)pa(dot)us> wrote in message
news:200104091744(dot)NAA12563(at)candle(dot)pha(dot)pa(dot)us(dot)(dot)(dot)

> 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(at)candle(dot)pha(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyle VanderBeek 2001-04-10 01:30:56 Re: JDBC int8 hack
Previous Message Gordon Runkle 2001-04-10 00:39:32 Re: release dates and announcements ?