From: | Philip Warner <pjw(at)rhyme(dot)com(dot)au> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Treat <rtreat(at)webmd(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: DB Tuning Notes for comment... |
Date: | 2002-12-09 23:40:19 |
Message-ID: | 5.1.0.14.0.20021210103350.0681f068@mail.rhyme.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 |/
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Warner | 2002-12-09 23:47:28 | Re: DB Tuning Notes for comment... |
Previous Message | Patrick Welche | 2002-12-09 23:39:17 | SIGSEGV |