On 2018/06/18 19:00, David Rowley wrote:
> 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.
I'm not sure of the vacuum (maybe NULL's the answer in that case), but if
we ever teach autovacuum the ability to *analyze* partitioned tables, then
we could simply record the time when that happens, instead of worrying
about how to aggregate across partitions. We could leave that NULL for
now, that is, if we decide to list partitioned tables in the
pg_stat_all_tables output at all re OP's complaint.
Thanks,
Amit
