On 2017/03/06 17:22, Michael Paquier wrote: > On Mon, Mar 6, 2017 at 4:18 PM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> About autovacuum_* parameters - we currently don't handle partitioned >> tables in autovacuum.c, because no statistics are reported for them. That >> is, relation_needs_vacanalyze() will never return true for dovacuum, >> doanalyze and wraparound if it is passed a RELKIND_PARTITIONED_TABLE >> relation. That's something to be fixed separately though. When we add >> autovacuum support for partitioned tables, we may want to add a new set of >> reloptions (new because partitioned tables still won't support all options >> returned by heap_reloptions()). Am I missing something? > > OK. I got confused by the fact that settings on parents should > super-seed the settings of the children. Or if you want if a value is > set on the parent by default it would apply to the child if it has no > value set, which is where autovacuum_enabled makes sense even for > partitioned tables.
Hmm, setting autovacuum_enabled on partitioned parent should be made to work after we have fixed autovacuum support for partitioned tables. Using the parent's value as a default for partitions may not be what we'd want eventually. > Leading to the point that parents could have > reloptions, with a new category of the type RELOPT_KIND_PARTITION. > Still, it is sensible as well to bypass the parents in autovacuum as > well, now that I read it. And the handling is more simple. We will need it though, because lack of automatically updated "inheritance" (or whole tree) statistics on partitioned tables is a problem. Thanks, Amit -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
