autovacuum stats under log_autovacuum_min_duration

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: autovacuum stats under log_autovacuum_min_duration
Date: 2012-11-25 05:51:30
Message-ID: CAMkU=1yvT_geB44j4f+v63HVHioc44uXfC+41nnqMY1ZLHuGgQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

While trying to decide of autovacuum was working optimally, I observed
some log messages like this:

9405 2012-11-24 01:01:25.982 PSTLOG: automatic vacuum of table
"jeff.pg_catalog.pg_class": index scans: 1
pages: 0 removed, 2441 remain
tuples: 86 removed, 84079 remain
system usage: CPU 0.00s/0.03u sec elapsed 2.83 sec

I thought it was odd that it would vacuum the table at all when there
is so little work to do.

But it turns out that since HOT was added, vacuum reports only the
number of pointers that were converted to dead item pointers by itself
as being removed, and doesn't count the number of dead item pointers
that were converted to unused item pointers, for the
"tuples:...removed" field. Since any process can do the former, there
might not be much of that type of work for vacuum to do for itself.
But only vacuum can do the latter. Wouldn't it be more useful to
report amount of work that vacuum is specialized for doing for this
number? I don't see the utility at all of reporting what it is
currently reporting.

Am I overlooking something?

Cheers,

Jeff

Browse pgsql-hackers by date

  From Date Subject
Next Message Chen Huajun 2012-11-25 12:02:33 Re: fix ecpg core dump when there's a very long struct variable name in .pgc file
Previous Message Jeff Janes 2012-11-25 05:42:08 Re: Use of fsync; was Re: Pg_upgrade speed for many tables