Re: pg_(total_)relation_size and partitioned tables - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: pg_(total_)relation_size and partitioned tables
Date
Msg-id d5323242-b571-9317-1e5b-ee5fd96c2f4a@2ndquadrant.com
Whole thread Raw
In response to Re: pg_(total_)relation_size and partitioned tables  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Responses Re: pg_(total_)relation_size and partitioned tables
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] taking stdbool.h into use
Next
From: Stephen Frost
Date:
Subject: Re: [HACKERS] replace GrantObjectType with ObjectType