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
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?) |