I am trying to better understand diskspace leakage and the
relationship to vacuum, max_fsm_pages, and max_fsm_relations.
Below are 3 snippets from 3 successive vacuums on a table
with ~284K rows which receives many many UPDATEs and a few
INSERTs (there were also a few runs of ANALYZE in between
these VACUUMs):
INFO: Pages 22652: Changed 4, Empty 0; Tup 284139: Vac 927, Keep 0, UnUsed 936.
INFO: Pages 22652: Changed 7, Empty 0; Tup 284151: Vac 423, Keep 0, UnUsed 1559.
INFO: Pages 22652: Changed 4, Empty 0; Tup 284155: Vac 221, Keep 0, UnUsed 1823.
This is on a newly-installed 7.3.4 cluster with max_fsm_pages
set to 3,000,000 (allowing for ~24GB of DB disk pages) and
max_fsm_relations = 2000.
Questions:
1) Do the increasing values for "UnUsed" indicate leakage?
Looks to me like the number of new rows were 12 and 4
respectively between vacuum runs. But the UnUsed values
seem to be jumping maybe roughly with the number of updates.
It's early, but I would expect vacuum to keep UnUsed low.
2) I understand max_fsm_relations needs to be at least as
high as the number of tables for which I want to track free
space. I have far fewer than 2000 user tables, but if I count
system tables and index relations, then I exceed 2000 by 10%
or so. Should I count system tables when setting max_fsm_relations?
3) Should I count index relations when setting max_fsm_relations?
TIA.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
