Robert Treat <xzilla@users.sourceforge.net> writes:
> On Thursday 08 September 2005 13:16, Andrew Dunstan wrote:
>> Initdb already
>> has adaptive rules - look at the source - and Tom suggests adding
>> another set for max_fsm_pages. All I'm doing is to suggest that we need
>> to tweak those.
> I'm curious how this could work... istm its fairly hard to predict a
> reasonable value for max_fsm_pages before you ever create a single database
> in your cluster... I could perhaps see this as becoming self tuning with an
> integrated autovacuum, where autovacuum stores the values needed for this and
> max_fsm_relations so that upon any restart these values get automatically
> updated to a reasonable number. Even more ideal would be to not have them
> require restart at all, but thats yet another level of magic...
It'd be nice to get out from under the fixed-size-shmem restriction, but
I don't know any very portable way to do that. In the meantime, trying
to automatically change the size parameters as above seems a tad
dangerous. What if they get updated to values that prevent the
postmaster from starting because it exceeds SHMMAX? Failing during
initdb is one thing, but not coming back after a restart is bad.
The thought behind my suggestion was that the current max_fsm_pages
default of 20000 pages is enough to track free space in a database of
maybe a few hundred megabytes. The other defaults are sized
appropriately for machines with about that much in main memory. This
doesn't seem to add up :-(. The default max_fsm_pages probably should
be about ten times bigger just to bring it in balance with the other
defaults ... after that we could talk about increasing the defaults
across-the-board.
regards, tom lane