On 2018/06/18 21:49, Michael Paquier wrote:
> On Mon, Jun 18, 2018 at 07:21:17PM +0900, Amit Langote wrote:
>> 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.
>
> Even for the last_* columns, it is not really possible to have one
> single definition for the partition parents. Here are a set of stats
> which could be useful depending on the context:
>
> - average of the last runs.
> - deviation of the last runs.
> - Latest one which ran.
> - Oldest one which ran.
That seems to assume that we'll never support certain operations whose
information appears in a row of a pg_stat_* view on partitioned table parents.
For example, suppose we add a feature where autovacuum forks a worker to
analyze partitioned table parent, wouldn't it be appropriate to have it
reported via pg_stat_* with that table having its own entry?
> The same applies for the tuples inserted and/or deleted, scans,
> etc. Users may want to know the deviation to check for the balance
> across partitions, or the sum of them, or even the average. For those
> reasons having entries in pg_stat_all_tables or such for parent
> partitions has little meaning, and having something which allows to grab
> a complete partition tree has way more value because it becomes easier
> to gather stats about the whole tree.
Yes, if we have such partition tree structure exposing function, users can
aggregate stats for partitions of a parent in all sorts of ways. But the
question is whether a row in pg_stat_* view for a parent is responsible
for showing it. If we ever have such rows, then I suppose it would show
the same information for partitioned tables as they do for normal tables,
but perhaps the amount of useful information would be much less than for
normal tables.
Thanks,
Amit