reading vacuum verbosity - Mailing list pgsql-general

From Ed L.
Subject reading vacuum verbosity
Date
Msg-id 200405202209.01360.pgsql@bluepolka.net
Whole thread Raw
Responses Re: reading vacuum verbosity
List pgsql-general
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.


pgsql-general by date:

Previous
From: Durai raj
Date:
Subject: postmaster shutdown failed
Next
From: "Paolo Tavalazzi"
Date:
Subject: slow query if add order by