Re: pg_(total_)relation_size and partitioned tables
От | Peter Eisentraut |
---|---|
Тема | Re: pg_(total_)relation_size and partitioned tables |
Дата | |
Msg-id | d5323242-b571-9317-1e5b-ee5fd96c2f4a@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: pg_(total_)relation_size and partitioned tables (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: pg_(total_)relation_size and partitioned tables
|
Список | pgsql-hackers |
On 12/18/17 00:17, Amit Langote wrote: > I agree with the Robert's point which both David and Michael seem to agree > with that we shouldn't really be changing what pg_relation_size() is doing > under the covers. And I guess the same for pg_table_size(), too. Both of > those functions and their siblings work with relations that possess > on-disk structures and have associated relations (TOAST, indexes) that in > turn possess on-disk structures. It seems quite clearly documented as > such. Partitioned tables are different in that they neither possess > on-disk structures nor have any relations (TOAST, indexes) associated > directly with them. Instead, they have partitions that are the relations > that aforementioned dbsize.c functions are familiar with. Here is another idea. If we had a function pg_partition_root(regclass) returns regclass (returning itself for non-partitioned relations), then users can easily construct queries to get the results they want in different shapes, e.g., select pg_partition_root(c.oid), c.relname, pg_table_size(c.oid) from pg_class c order by 1 select pg_partition_root(c.oid), sum(pg_table_size(c.oid)) from pg_class c group by 1 -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: