On Mon, Dec 18, 2017 at 2:17 PM, Amit Langote <langote_amit...@lab.ntt.co.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