Re: [PATCHES] Another POC initdb patch

[Tom Lane]

Shridhar Daithankar [EMAIL PROTECTED] writes:
 In addition to Tom's patch, this patch asks tuning parameters right away, 
 while doing initdb.

Sorry, there is zero chance of putting any interactivity into initdb.
Most RPM installations run it from the RPM install script and would be
unable to cope with this.

I disagree with the concept of expecting someone to supply useful values
at install time anyway, since a newbie is the *least* likely to have any
idea what to say at that time.  Heck, the experts can hardly agree on
what to use ...

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [PATCHES] Proof-of-concept for initdb-time shared_buffers selection

[Tom Lane]

Bruno Wolff III [EMAIL PROTECTED] writes:
 Should the default max number of connections first try something greater
 than what Apache sets by default (256 for prefork, 400 for worker)?

We could do that.  I'm a little worried about setting default values
that are likely to cause problems with exhausting the kernel's fd table
(nfiles limit).  If anyone actually tries to run 256 or 400 backends
without having increased nfiles and/or twiddled our
max_files_per_process setting, they're likely to have serious problems.
(There could be some objection even to max_connections 100 on this
ground.)

We could imagine having initdb reduce max_files_per_process to prevent
such problems, but then you'd be talking about giving up performance to
accommodate a limit that the user might not ever approach in practice.
You really don't want the thing selecting parameters on the basis of
unrealistic estimates of what max_connections needs to be.

Ultimately there's no substitute for some user input about what they're
planning to do with the database, and possibly adjustment of kernel
settings along with PG settings, if you're planning to run serious
applications.  initdb can't be expected to do this unless you want to
make it interactive, which would certainly make the RPM guys really
unhappy.

I'd rather see such considerations pushed off to a separate tool,
some kind of configuration wizard perhaps.

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly