Re: Simple postgresql.conf wizard - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Simple postgresql.conf wizard
Date
Msg-id 603c8f070812031329i257de253p8c2f6c9c751fcd89@mail.gmail.com
Whole thread Raw
In response to Re: Simple postgresql.conf wizard  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: Simple postgresql.conf wizard  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-hackers
> Well did you have any response to what I posited before? I said "mixed" should
> produce the same settings that the default initdb settings produce. At least
> on a moderately low-memory machine that initdb targets.

I'm actually really skeptical of this whole idea of modes.  The main
thing mode does, other than set max connections, is handle desktop
differently than other modes by decreasing shared_buffers and
effective_cache_size by 4x and work_mem by 3x.  And the default
settings for max_connections are a SWAG that could easily be way off
for any particular installation.  I think it would be more useful to
get rid of modes, accept the user is going to have to specify
max_connections if the default of, say, 100 is not reasonable, and
handle the desktop case by telling the user to rerun the tool
overriding the system memory with a lower value.

I'm not sure if you've thought about this, but there is also a
difference between max_connections and maximum LIKELY connections.
For example my apps don't have too many users, since they are
internal-facing.  But setting max_connections to 100 gives me a nice
buffer just in case everyone decides to log on at once.  Still, for
performance reasons, I'd prefer to calculate based on a more likely
scenario, where the concurrent user count might be only 10 or 20.

...Robert


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Simple postgresql.conf wizard
Next
From: "Robert Haas"
Date:
Subject: Re: Simple postgresql.conf wizard