Re: pg_(total_)relation_size and partitioned tables

On Mon, Dec 18, 2017 at 2:17 PM, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> Do you (and/or others) think that's something that we can wrap inside a
> built-in function(s), that is, one defined in system_views.sql? Or if we
> decide to have new functions, say, pg_get_partitions() and/or
> pg_get_partition_sizes(), we might as well implement them as C functions
> inside dbsize.c. If so, do we have want to have "partition" variants of
> all *_size() functions viz. pg_relation_size(), pg_total_relation_size(),
> pg_indexes_size(), and pg_table_size()?

I can see value in something like Robert is proposing upthread by
having a function one is able to customize to decide what to include
in the calculation. There could be options for at least:
- partitions, or relation cascading.
- index.
- toast tables.
- visibility maps.
- FSM.
The first three ones is what Robert are mentioned, still I would see
the last two ones are interesting things if optional. Or we could have
just a SRF that returns one row per object scanned.
--
Michael