From: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: DB Tuning Notes for comment... |
Date: | 2002-12-10 02:10:38 |
Message-ID: | pan.2002.12.09.21.10.34.766510.1243@users.sourceforge.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 09 Dec 2002 19:10:23 -0500, Tom Lane wrote:
> Philip Warner <pjw(at)rhyme(dot)com(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2002-12-10 03:10:58 | Re: DB Tuning Notes for comment... |
Previous Message | Philip Warner | 2002-12-10 01:55:51 | Re: psql's \d commands --- end of the line for |