Re: relkind='p' has no pg_stat_user_tables

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: relkind='p' has no pg_stat_user_tables
Date: 2018-05-04 14:13:33
Message-ID: 20180504141333.GF1592@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, May 03, 2018 at 01:24:59PM -0500, Justin Pryzby wrote:
> Yes, I was surprised about the difference between ANALYZE relkind_p
> and relkind_r.
>
> But I see that's a documented behavior I'd missed until now:
>
> https://www.postgresql.org/docs/current/static/sql-analyze.html
> |If the specified table is a partitioned table, both the inheritance statistics
> |of the partitioned table as a whole and statistics of the individual partitions
> |are updated.

When I read this thread, it seems to me that more user-friendly system
functions able to extract a sub-tree of child relations (by inheritance
and/or partition) is something which would help. Now users are limited
to things like large WITH RECURSIVE queries when willing to extract a
full tree. While that's easily done with a custom function, there is
room for an in-core function as well. I recall that Amit Langote has
sent a patch which introduces a wrapper function on top of
find_all_inheritors, perhaps that would get into v12.
--
Michael

In response to

Browse pgsql-general by date

  From Date Subject
Next Message nikhil raj 2018-05-04 16:45:41 Re: How to find the hits on the databases and tables in Postgres
Previous Message Tom Lane 2018-05-04 13:32:08 Re: Query planner riddle (array-related?)