Hi everybody,
I'm trying to understand how vacuumdb and free
space map work together for retrieving free spaces after delete or update
statements.
max_fsm_pages and max_fsm_relations
are set to default values (respectively 10000 and 100).
I do my tests on a table containing at the
beginning 1931968 tuples stocked in 11944 pages :
INFO: Pages 11944: Changed 11944, Empty 0; Tup 1931968: Vac 0, Keep 0, UnUsed 0 I delete 1931936 tuples (letting 32 tuples
left).
I thought the number of pages affected by this
delete will overflow fsm storage capacity, but when I run a vacuumdb verbose
analyze on this table,
I have the following log information :
INFO: Removed 1397914 tuples in 8641
pages. CPU
0.76s/0.89u sec elapsed 25.72 sec. INFO: Removed 534022 tuples in 3303
pages. CPU
0.37s/0.29u sec elapsed 7.62 sec. INFO: Pages 11944: Changed 11944, Empty 0; Tup
32: Vac 1931936, Keep 0, UnUsed 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 8641+3303=11944 pages (>10000 which was set for
max_fsm_page).
Can someone explain me, where I'm wrong
?
My first aim was to know if max_fsm_pages was set for each table or for a whole
database. Per table I suppose, but Is it a good supposition ?
Where is stored (on disk) this fsm ?
Thanks for your answers.
Luc |
- Re: [ADMIN] max_fsm_pages Jouneau Luc
- Re: [ADMIN] max_fsm_pages Tom Lane