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

An excellent idea.

I suspect you'll get a biased resonse from the -hackers folks. This really
is an excellent idea.

Those options cover I think the main scenarios, with the first two options
being the most important. Ideally you'd basically sample server specs
(speed, # of procs, mem etc) and set up for that based on profile. It should
then be possible to dump the settings that are used (--tuning = these
cmdline --options changed from defaults).

Novices can use it to get of the ground, intermediate level dba's can use it
as a sizing tool, and -hackers can flame each other over its very existence.

August

----- Original Message -----
From: "Justin Clift" <jclift@iprimus.com.au>
Newsgroups: comp.databases.postgresql.hackers
Sent: Sunday, April 08, 2001 11:36 PM
Subject: "--tuning" compile and runtime option (?)


> Hi guys,
>
> Just thinking about the future directions PostgreSQL is taking, and it
> seems (just a feeling) like most people prefer it to be as self tuning
> as possible.
>
> In trying to think about how it will/would do that I think PostgreSQL
> will need to know "how much" of the resources of the server its on, it's
> allowed to take.
>
> Can think of three scenario's, 1) Single-purpose PostgreSQL server 2)
> shared function server (i.e. Apache, Postgres, etc on the same box) 3)
> Embedded or otherwise resource limited server (Palmtop, etc).
>
> When we get around to PostgreSQL's self-tuning ability being actively
> developed (and I think Bruce has done some of the very start with his
> monitor program), perhaps having a compile time option to set the
> default for the server, and a runtime option in case it changes?
>
> i.e.
>
> --tuning=superserver
> --tuning=shared
> --tuning=embedded
>
> postmaster -t superserver
> postmaster -t shared
> postmaster -t embedded
>
> What do people think?
>
> Regards and best wishes,
>
> Justin Clift
>