On Sun, Dec 17, 2017 at 11:54 PM, David Rowley <david.row...@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
