On Fri, Feb 17, 2017 at 1:12 PM, Amit Langote
>> I agree. But, we need to be careful that a database-wide VACUUM or
>> ANALYZE doesn't hit the partitions multiple times, once for the parent
>> and again for each child. Actually, a database-wide VACUUM should hit
>> each partition individually and do nothing for the parents, but a
> This is what would happen even without the patch. Patch only modifies
> what happens when a partitioned table is specified in the vacuum command.
> It emits a warning:
> WARNING: skipping "%s" --- cannot vacuum partitioned tables
> It seems both you and Simon agree that instead of this warning, we should
> recurse to process the leaf partitions (ignoring any partitioned tables in
> the hierarchy for which there is nothing to do). If that's right, I will
> modify the patch to do that.
Yeah, that sounds fine.
>> database-wide ANALYZE should process the parents and do nothing for
>> the children, so that the inheritance statistics get updated.
> Currently vacuum() processes the following relations:
> * Process all plain relations and materialized views listed in
> * pg_class
> while ((tuple = heap_getnext(scan, ForwardScanDirection)) != NULL)
> Form_pg_class classForm = (Form_pg_class) GETSTRUCT(tuple);
> if (classForm->relkind != RELKIND_RELATION &&
> classForm->relkind != RELKIND_MATVIEW)
> Do you mean that if database-wide analyze is to be run, we should also
> exclude those RELKIND_RELATION relations that are partitions?
> So the only way to update a partition's statistics is to directly specify
> it in the command or by autovacuum.
I think if you type:
...that should process all partitioned tables and all tables that are
not themselves partitions. If you type:
...that should ANALYZE that relation, whatever it is. If it's a
partitioned table, it should recurse.
> Truncate already recurses to partitions by way of inheritance recursion
> that's already in place. The patch simply teaches ExecuteTruncate() to
> ignore partitioned tables when we get to the part where relfilenodes are
Oh, OK. That seems fine.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: