From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | Ron Mayer <ron(at)intervideo(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: "analyze" putting wrong reltuples in pg_class |
Date: | 2002-08-04 02:13:21 |
Message-ID: | 6176.1028427201@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Is there any way we can warn users when their fsm parameters are too
> small?
Not until we understand what too small is :-( If anyone's undertaken
any experiments to figure out what an appropriate FSM size setting is,
I'm not aware of it.
The default setting is 10000 pages which would certainly cover all the
free space in 8K*10000 = 80meg of tables, and in practice would cover
significantly more space as long as most of your pages weren't updated
often (and hence didn't have free space to worry about). But obviously
this number is on the low side for production databases, especially
large ones. We need to put "pay attention to FSM size" right after
"pay attention to shared_buffers" in the standard list of tuning tips.
Presumably there's some tradeoff curve that says max_fsm_pages should
cover X% of your physical database page count if you update Y% of the
database rows between vacuums. I'm not sure what the curve looks like
though --- the real issue is how many distinct pages are likely to be
touched when you update so-and-so many rows?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-08-04 02:25:54 | Re: Bug #728: Interactions between bytea and character encoding when doing analyze |
Previous Message | Joe Conway | 2002-08-04 01:22:07 | Re: Bug #728: Interactions between bytea and character encoding |