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

From Robert Haas
Subject Re: pg_(total_)relation_size and partitioned tables
Date
Msg-id CA+TgmoYHSeFb-W4Bv7N2weqpj1Jub2kPP4BwPALwEJe8Vngrrg@mail.gmail.com
Whole thread Raw
In response to Re: pg_(total_)relation_size and partitioned tables  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
On Sun, Dec 17, 2017 at 9:54 AM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> I'd also vote to leave the relation_size functions alone.
>
> Perhaps it's worth thinking of changing pg_table_size() instead. We
> have taken measures to try and hide the fact that a table is made up
> of a bunch of partitions from the user in some cases, e.g DROP TABLE
> works without CASCADE for a partitioned table. I'm sure there are
> arguments in both directions here too though.

Yeah, I don't really understand why changing pg_table_size() is any
more desirable than changing pg_relation_size().

I mean, we could have a table-size function that takes an array of
things you want to include (indexes, toast, partitions, etc), but
changing the semantics of existing functions seems like it's going to
be more painful than helpful (aside from the arguments I brought up
before).

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Protect syscache from bloating with negative cache entries
Next
From: Michael Paquier
Date:
Subject: Re: pg_(total_)relation_size and partitioned tables