On Sun, Dec 17, 2017 at 11:54 PM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> I'd also vote to leave the relation_size functions alone.
Count me in that bucket as well.
> Perhaps it's worth thinking of changing pg_table_size() instead. We
> have taken measures to try and hide the fact that a table is made up
> of a bunch of partitions from the user in some cases, e.g DROP TABLE
> works without CASCADE for a partitioned table. I'm sure there are
> arguments in both directions here too though.
>
> I generally think of the difference between a relation and a table
> similarly to the difference between a tuple and a row. A relation is
> just what we use to implement tables, and there can be multiple
> relations per table (in the partitioning case), similar to how there
> can be multiple tuple versions for a single row. So that might back up
> that pg_table_size should include all relations that make up that
> table.
The barrier here is thin. What's proposed here is already doable with
a WITH RECURSIVE query. So why not just documenting this query and be
done with it instead of complicating the code? It seems to me that the
performance in calling pg_relation_size() in a cascading times fashion
would not matter much. Or one could invent an additional cascading
option which scans inheritance and/or partition chains, or simply have
a new function.
--
Michael