| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Jouneau Luc" <Luc(dot)Jouneau(at)jouy(dot)inra(dot)fr> |
| Cc: | pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: max_fsm_pages |
| Date: | 2003-09-04 23:24:04 |
| Message-ID: | 12061.1062717844@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
"Jouneau Luc" <Luc(dot)Jouneau(at)jouy(dot)inra(dot)fr> writes:
> INFO: Pages 11944: Changed 11944, Empty 0; Tup 32: Vac 1931936, Keep 0, Un=
> Used 0.
> Total CPU 1.57s/1.90u sec elapsed 42.01 sec.
> It seems that FSM traced all of my deletes since it mentions removes in 864=
> 1+3303=3D11944 pages (>10000 which was set for max_fsm_page).
The numbers output by VACUUM don't tell you anything about how many of
those pages will actually be remembered in the FSM.
In practice, max_fsm_relations=100 is too small; we've bumped the
default to 1000 for 7.4.
> My first aim was to know if max_fsm_pages was set for each table or for a w=
> hole database.
Whole database. That default setting is very small, too (enough for
a database of maybe a couple hundred meg, at most).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Murthy Kambhampaty | 2003-09-04 23:29:20 | Re: Seeking information about backup/recovery |
| Previous Message | Josh Goldberg | 2003-09-04 23:07:08 | experimenting with coalesce, strange EXPLAIN results |