From: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | reading vacuum verbosity |
Date: | 2004-05-21 04:09:01 |
Message-ID: | 200405202209.01360.pgsql@bluepolka.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
From | Date | Subject | |
---|---|---|---|
Next Message | Durai raj | 2004-05-21 04:11:57 | postmaster shutdown failed |
Previous Message | Christopher Browne | 2004-05-21 03:00:05 | Re: Am I locking more than I need to? |