Re: Proof-of-concept for initdb-time shared_buffers selection - Mailing list pgsql-patches

From Tom Lane
Subject Re: Proof-of-concept for initdb-time shared_buffers selection
Date
Msg-id 11025.1057521465@sss.pgh.pa.us
Whole thread Raw
In response to Re: Proof-of-concept for initdb-time shared_buffers selection  (Bruno Wolff III <bruno@wolff.to>)
List pgsql-patches
Bruno Wolff III <bruno@wolff.to> 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

pgsql-patches by date:

Previous
From: Bruno Wolff III
Date:
Subject: Re: Proof-of-concept for initdb-time shared_buffers selection
Next
From: Shridhar Daithankar
Date:
Subject: Re: Another POC initdb patch