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: | Raw Message | Whole Thread | 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 |