Re: pg_(total_)relation_size and partitioned tables

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_(total_)relation_size and partitioned tables
Date: 2018-01-02 13:45:34
Message-ID: 93bef1b2-2ed0-c257-158e-efdf5b0ff9dd@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/28/17 16:24, David Rowley wrote:
>> 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
>
> That seems much nicer. I assume "root" would mean the top level
> partitioned table. If so, would we also want
> pg_partition_parent(regclass)? Or maybe something to control the
> number of "levels-up" the function would run for. If we had that then
> maybe -1 could mean "go until you find a table with no parent".

Hmm, we need to think through some scenarios for what one would really
want to do with this functionality.

Clearly, the existing behavior is useful for management tasks like bloat
and vacuum monitoring.

And on the other hand you might want to have a logical view of, how big
is this partitioned table altogether.

But what are the uses for dealing with partial partition hierarchies?
How easy do we need to make that?

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tels 2018-01-02 13:45:47 Re: Faster inserts with mostly-monotonically increasing values
Previous Message Devrim Gündüz 2018-01-02 13:43:35 Re: How to Works with Centos