On 18 June 2018 at 21:48, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote:
> On 2018/06/18 11:06, Michael Paquier wrote:
>> On Sun, Jun 17, 2018 at 08:29:33AM -0700, David G. Johnston wrote:
>>> My first reaction was to agree, which suggests a need for a note in the
>>> docs why this isn't the case. The _all_ specifically means both user and
>>> system; the _stats_ in the name means that only tables that have statistics
>>> are included. I feel this is a reasonable decision.
>>
>> If there were anything to happen here, then I think that it would be
>> hard to define what the statistics of the parent partition should
>> reflect. For example, the autovacuum and autoanalyze run times are I
>> think tricky as you cannot really define the last time autovacuum has
>> been run on the parent as the last time it has been run only only one of
>> the partitions or a sub-set of them. This gets also messier if you come
>> across multiple partition layers.
>
> I think autovacuum launcher ignores/skips relkind 'p' relations. Also, we
> don't emit any kind of statistics for relkind 'p' relations to the stats
> collector, as individual inserts/deletes into such relations are rather
> counted as insert/deletes on partitions into which they're routed.
I think what Michael was meaning is that there is no clear way to
aggregate the last_* columns in that view. For the bigint columns,
it's a bit more clear, probably taking the sum() of all partitions
would be the way to go. However, what do you do with the timestamp
columns? Max()... ? it was only really a "partial" vacuum of the
partitioned table, so maybe NULL? I'm not sure.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
