Re: Table-level log_autovacuum_min_duration - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Table-level log_autovacuum_min_duration
Date
Msg-id CAB7nPqRZo7H-MGsXpvt_ibg265yWVm3j0=mxyAXxmDAO0UW9SA@mail.gmail.com
Whole thread Raw
In response to Re: Table-level log_autovacuum_min_duration  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Table-level log_autovacuum_min_duration
List pgsql-hackers
On Sat, Dec 20, 2014 at 11:17 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
>> Michael Paquier wrote:
>>> Today I spent a bit of time looking at the activity of autovacuum for
>>> one table particularly bloated. log_autovacuum_min_duration was
>>> enabled and set to a high value but even with that I had to deal with
>>> some spam from the jobs of other tables. It would be cool to have the
>>> possibility to do some filtering IMO. So, what about having a relopt
>>> to control log_autovacuum_min_duration? RelationData->rd_options is
>>> largely accessible for a given relation in the code paths of vacuum
>>> and analyze.

OK, instead of only words, attached is a patch adding relopts called
log_autovacuum_min_duration and toast.log_autovacuum_min_duration to
control the logging of autovacuum at relation-level. The default value
of those parameters is -1, meaning that in this case the global
log_autovacuum_min_duration is used to control the logs. The patch has
finished by being simpler than I though first by using VacuumStmt to
pass the relopts from autovacuum to the code paths of analyze and
vacuum. Note that this uses the same mechanisms as the other relopts,
meaning that the toast relations use the values of their parent tables
if it is defined.

I am adding it to the next CF.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: WITH CHECK and Column-Level Privileges
Next
From: Magnus Hagander
Date:
Subject: New CF app deployment