From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: Michael Paquier <michael@paquier.xyz>
Cc: David Rowley <david.rowley@2ndquadrant.com>
Cc: David G. Johnston <david.g.johnston@gmail.com>
Cc: Mahadevan Ramachandran <mahadevan@rapidloop.com>
Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #15245: pg_stat_all_tables does not include partition master tables
Date: Tue, 19 Jun 2018 10:49:17 +0900
Message-ID: <4afa024b-dc62-cfed-41a3-d7975c66ed7a@lab.ntt.co.jp> (raw)
In-Reply-To: <20180618124943.GB1721@paquier.xyz>
References: <152922564661.24801.3078728743990100425@wrigleys.postgresql.org>
<20180617120653.GD1411@paquier.xyz>
<CADjCDK9APQLYPt4F2TH5xSEEYjFCe7nLphEe7L7EHV7-WuAB_A@mail.gmail.com>
<CAKFQuwaV0Zz5_e7CmJoP_ULRsZ-G2y6fmMF-4QZP6eGso3J7Dg@mail.gmail.com>
<20180618020642.GC3721@paquier.xyz>
<16ac0ae3-f0ba-536f-92e2-4a954dce8bbf@lab.ntt.co.jp>
<CAKJS1f98mP75ki_gbOfXffhC4FsEtURgVunO8Z0eZN-5m5ji-A@mail.gmail.com>
<a44eb853-fda3-29f5-9b4d-1cc65b1485ab@lab.ntt.co.jp>
<20180618124943.GB1721@paquier.xyz>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: Langote_Amit_f8@lab.ntt.co.jp, michael@paquier.xyz, david.rowley@2ndquadrant.com, david.g.johnston@gmail.com, mahadevan@rapidloop.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15245: pg_stat_all_tables does not include partition master tables
In-Reply-To: <4afa024b-dc62-cfed-41a3-d7975c66ed7a@lab.ntt.co.jp>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox