Re: Table-level log_autovacuum_min_duration

On Sat, Dec 20, 2014 at 9:17 AM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)com> wrote:
> But now, here are some things to consider if we use directly the
> reloptions available with RelationData:
> - If the parameters toast.autovacuum_* are not set, toast relations
> inherit values from their parent relation. Looking at autovacuum.c
> which is the only place where autovacuum options are located, we keep
> a hash table to save the mapping toast -> parent relation. Using that
> it is easy to fetch for a given toast relation the relopts of its
> parent. Note this is strictly located in the autovacuum code path, so
> to let vacuum and analyze now the custom value of
> log_autovacuum_min_duration, with the inheritance property kept, we
> would need to pass some extra values from autovacuum to the calls of
> vacuum().
> - It would not be possible to log autovacuum and analyze being skipped
> when lock is not available because in this case Relation cannot be
> safely fetched, so there are no reltoptions directly available. This
> is for example this kind of message:
> skipping analyze of "foo" --- lock not available
>
> Both those things could be solved by passing a value through
> VacuumStmt, like what we do when passing a value for
> multixact_freeze_min_age, or with an extra argument in vacuum() for
> example. Now I am not sure if it is worth it, and we could live as
> well with a parameter that do not support the inheritance parent
> relation -> toast, so log value set for a toast relation and its
> parent share no dependency. In short that's a trade between code
> simplicity and usability.

I'm not sure I follow all of the particulars of what you are asking
here, but in general I would say that you shouldn't hesitate to pass
more information down the call stack when that helps to obtain correct
behavior.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company