From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | "Tambet Matiisen" <t(dot)matiisen(at)aprote(dot)ee>, "Bill Chandler" <billybobc1210(at)yahoo(dot)com>, "pgsql-perform" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Question on REINDEX |
Date: | 2005-04-19 16:24:02 |
Message-ID: | 22304.1113927842@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
>> select count(1), sum(relpages) from pg_class where relkind in
>> ('r','i','t')
> Well, if you do that for all databases in the cluster, it's the number you
> start with. However, setting FSM_pages to that would be assuming that you
> excpected 100% of the rows to be replaced by UPDATES or DELETEs before you
> ran VACUUM. I generally run VACUUM a little sooner than that.
Not at all. What it says is that you expect 100% of the pages to have
useful amounts of free space, which is a *much* weaker criterion.
I think you can usually get away with setting max_fsm_pages to less than
your actual disk footprint, but I'm not sure how much less. It'd
probably depend a lot on your usage pattern --- for instance,
insert-only history tables don't need any FSM space.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mohan, Ross | 2005-04-19 16:25:24 | Re: How to improve db performance with $7K? |
Previous Message | Richard_D_Levine | 2005-04-19 16:22:17 | Re: How to improve db performance with $7K? |