On Sat, Dec 20, 2014 at 9:17 AM, Michael Paquier <michael.paqu...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
