At 03:54 PM 9/12/2002 -0500, Tom Lane wrote:
>However, I suspect that the present FSM code is not very effective at
>deciding *which* tables to track if it has too few slots,
You are definitely right there.
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...
AFAICT, the only justification for a smaller list of relations is for those
that are *almost never* subject to deletes or updates. They are certainly
common in DB design, but I'd let the DBA designate them.
Does this sound reasonable?
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
Http://www.rhyme.com.au | / \| | --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/