Tom Lane wrote:
>Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>>Nearly everyone seems to agree that the default for max_fsm_pages is
>>woefully low, so I would like to have the default for this set
>>unconditionally to 200,000 rather than 20,000. The cost would be just
>>over 1Mb of shared memory, if the docs are correct. Alternatively, we
>>could put this into the mix that is calculated by initdb, scaling it
>>linearly with shared_buffers (but with the default still at 200,000).
>>I would also like to propose a more modest increase in max_connections
>>and shared_buffers by a factor of 3.
>I don't mind having initdb try larger values to see if they work, but
>if you are suggesting that we try to force adoption of larger settings
>I'll resist it.
OK, works for me. The only thing I suggested might be set in stone was
max_fsm_pages; I always envisioned the others being tested as now by initdb.
>"Factor of three" seems mighty weird. The existing numbers (100 and 1000)
>at least have the defensibility of being round.
What numbers would you like? If what I suggested seems odd, how about
targets of 400 connections, 4000 shared_buffers and 200,000 max_fsm_pages?
In response to
pgsql-hackers by date
|Next:||From: Andreas Pflug||Date: 2005-12-12 16:39:11|
|Subject: Re: pg_relation_size locking|
|Previous:||From: Tom Lane||Date: 2005-12-12 16:10:41|
|Subject: Re: Different length lines in COPY CSV |
pgsql-patches by date
|Next:||From: Tony S||Date: 2005-12-12 16:18:53|
|Subject: Re: BUG #2108: Function with OUT parameters not recognized,|
|Previous:||From: Tom Lane||Date: 2005-12-12 15:34:06|
|Subject: Re: BUG #2108: Function with OUT parameters not recognized, using plpgsql |