Re: reading vacuum verbosity - Mailing list pgsql-general

From Tom Lane
Subject Re: reading vacuum verbosity
Date
Msg-id 24931.1085123048@sss.pgh.pa.us
Whole thread Raw
In response to reading vacuum verbosity  ("Ed L." <pgsql@bluepolka.net>)
Responses Re: reading vacuum verbosity
List pgsql-general
"Ed L." <pgsql@bluepolka.net> writes:
> 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.

That looks okay to me considering that the physical table size (Pages)
isn't growing.

> 1)  Do the increasing values for "UnUsed" indicate leakage?

I'm not sure.  It seems a bit odd ... could you track this over a longer
interval?  An unused tuple slot will only take 4 bytes so it might take
awhile to see any real consequence.

> Should I count system tables when setting max_fsm_relations?

Yes.

> 3)  Should I count index relations when setting max_fsm_relations?

As of 7.4, yes.

            regards, tom lane

pgsql-general by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Am I locking more than I need to?
Next
From: Tom Lane
Date:
Subject: Re: can't get async mode to deliver small batches of rows