From: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
---|---|
To: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Process title for autovac |
Date: | 2013-04-07 00:25:28 |
Message-ID: | 5160BCF8.4000102@catalyst.net.nz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 07/04/13 08:20, Jeff Janes wrote:
> I've often wanted to know what the autovacuum worker was doing. The
> process title seems like the best place to get this information, but the
> process title tells me what database it is in, but not what table it is
> working on.
>
> The attached patch demonstrates the concept of what I want. I put the
> code in table_recheck_autovac not because I think that is the best
> location, but just because it was the easiest point at which I knew how
> to get the table name easily before classTup gets destroyed.
>
> Example output:
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 16392 jjanes 20 0 229m 19m 6948 S 3.6 1.0 0:06.85 postgres:
> autovacuum worker process jjanes.public.pgbench_accounts
>
>
> I never reset the process title back to the initial state of just having
> a database name and no table. Which I can get away with temporarily
> because the autovac worker never dilly-dallies between tables, it either
> goes to the next one, or exits. A real implementation would probably
> want to reset it anyway, though.
>
> Is this functionality something we want? If so should it include
> explicit vacuum as well as autovac? Any opinion about where in the code
> base it properly belongs (which obviously depends on whether it should
> cover manual vacuum as well)? And does the string need to distinguish
> between an autovac and an autoanalyze?
> Cheers,
>
> Jeff
>
Knowing whether it is vacuuming or analyzing seems like a nice idea +1
Cheers
Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2013-04-07 00:53:48 | Re: Unrecognized type error (postgres 9.1.4) |
Previous Message | Joe Conway | 2013-04-06 23:49:35 | Re: pg_dump selectively ignores extension configuration tables |