U can install pgstattuple module which is available in the contrib directory
and run it on production as

psql\x
psqlselect * from pgstattuple('public'.'tablename');

it displays the table_len, tuple_count, tuple_len, tuple_percent,
dead_tuple_count, dead_tuple_len,dead_tuple_percent,free_space,free_ percent
for the table .

5/16/06, Chris Hoover <revoohc (AT) gmail (DOT) comwrote:

Thanks to those who answered my first question. I am looking at
implementing autovacuuming on our new production 8.1.3 systems. I am
reading the documentation on the various configuration parameters. The
autovacuum_analyze_threshold and autovacuum_vacuum_threshold talk about the
number of updated and deleted tuples. Is there anyway to calculate these
numbers in a running database?

The reason I'm asking is that we are having some sporadic slowness issues
with our databases, and I'm wanting to see how the database looks during
these times. I know that vacuuming some specific tables tends to fix the
problem. So, if I can see what autovacuum might see, I could set the
parameters correctly to try and fix the issue.

Anyway, are these number available to me?

Thanks,
--
Chris

Tue, May 16, 2006 at 02:00:21PM -0400, Chris Hoover wrote:
Thanks to those who answered my first question. I am looking at
implementing autovacuuming on our new production 8.1.3 systems. I am
reading the documentation on the various configuration parameters. The
autovacuum_analyze_threshold and autovacuum_vacuum_threshold talk about the
number of updated and deleted tuples. Is there anyway to calculate these
numbers in a running database?

The reason I'm asking is that we are having some sporadic slowness issues
with our databases, and I'm wanting to see how the database looks during
these times. I know that vacuuming some specific tables tends to fix the
problem. So, if I can see what autovacuum might see, I could set the
parameters correctly to try and fix the issue.

Your best bet is to turn up your logging verbosity, so that you actually
get more detailed info from autovacuum. Short of that, you can monitor
those tables in pg_stat_user_tables; in particular you need to watch
n_tup_upd and n_tup_del.

As for the autovacuum settings, I've found that the default threasholds
and scale factors are too big by at least a factor of 2. By default, it
will allow a relation to grow to 40% dead rows before vacuuming, which
is a pretty decent amount of waisted space.

Finally, there are certain tables that aren't well suited to autovacuum,
namely any tables that see a very high rate of updates or deletes. For
these tables I usually schedule vacuums via crontab. For tables that
should be kept small (ie: queue tables), I'll even go as far as
vacuuming once a minute, or more often, since these tables should stay
small enough for vacuum to be very fast.