At 03:54 PM 9/12/2002 -0500, Tom Lane wrote:
You are definitely right there.However, I suspect that the present FSM code is not very effective at deciding *which* tables to track if it has too few slots,
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 |/
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
