On Mon, 09 Dec 2002 19:10:23 -0500, Tom Lane wrote: > Philip Warner <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
