From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org, pgsql-patches(at)postgreSQL(dot)org |
Subject: | Re: Proof-of-concept for initdb-time shared_buffers selection |
Date: | 2003-07-31 13:43:21 |
Message-ID: | 1027.1059659001@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Manfred Koizar <mkoi-pg(at)aon(dot)at> writes:
> On Fri, 04 Jul 2003 15:29:37 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> wrote:
>> The attached patch shows how initdb can dynamically determine reasonable
>> shared_buffers and max_connections settings that will work on the
>> current machine.
> Can't this be done on postmaster startup?
Why would that be a good idea? Seems to me it just offers a fresh
opportunity to do the wrong thing at every startup. We'v had troubles
enough with problems that appear only when the postmaster is started by
hand rather than by boot script, or vice versa; this would just add
another unknown to the equation.
> This would make the lives easier for the folks trying to come up with
> default .conf files, e.g.
> min_shared_buffers = 64
> max_shared_buffers = 2000
> could cover a fairly large range of low level to mid level machines.
Not unless their notion of a default .conf file includes a preinstalled
$PGDATA directory. Under ordinary circumstances, initdb will get run
locally on the target machine, and should come up with a valid value.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-07-31 13:58:31 | Re: version mismatch message |
Previous Message | Andreas Pflug | 2003-07-31 12:39:21 | Re: followup on previous |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-07-31 14:05:25 | Re: Check for failed memory allocations in libpq |
Previous Message | Tom Lane | 2003-07-31 13:37:44 | Re: [Fwd: Re: ruleutils with pretty-print option] |