On Mon, 09 Dec 2002 19:10:23 -0500, Tom Lane wrote:
> Philip Warner <pjw@rhyme.com.au> writes:
>> I think it would be worth looking at removing max_fsm_tables as a
>> tuning option, and adding a 'relhasfsm' flag to pg_class for those
>> tables that should not be mapped. Default to 't'. Then, make the table
>> grow dynamically as tables are added, or when a VACUUM occurs...
>
> If we could "make the table grow dynamically" then there'd not be much
> need for the config parameters at all. The real problem is to fit into
> a shmem segment whose size has to be frozen at postmaster start (which,
> not incidentally, is before we've ever looked at the database...). We
> could make the constraint be on total space for relation entries + page
> entries rather than either individually, but I think that'd mostly make
> it harder to interpret the config setting rather than offer any real
> ease of administration.
>
Can we not just have vacuum of a database return a total # of pages
modified and relations modified, and then report suggested free space map
settings? Even this little bit would be a step in the right direction.
Robert Treat