Re: Partitioned tables and relfilenode
Michael Paquier <michael.paquier@gmail.com>
From: Michael Paquier <michael.paquier@gmail.com>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Robert Haas <robertmhaas@gmail.com>,
Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, Simon Riggs <simon@2ndquadrant.com>,
Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2017-03-06T08:22:11Z
Lists: pgsql-hackers
On Mon, Mar 6, 2017 at 4:18 PM, Amit Langote <Langote_Amit_f8@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. 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. -- Michael
Commits
-
Code review for c94e6942cefe7d20c5feed856e27f672734b1e2b.
- 1d5fede4a900 10.0 landed
-
Don't allocate storage for partitioned tables.
- c94e6942cefe 10.0 landed
-
Don't scan partitioned tables.
- d3cc37f1d801 10.0 landed
-
Don't uselessly rewrite, truncate, VACUUM, or ANALYZE partitioned tables.
- 3c3bb99330aa 10.0 landed