Bruce Momjian wrote:

Dave Page wrote:

pg_relation_size(text)   - Get relation size by name/
pg_relation_size(oid)    - Get relation size by OID
pg_tablespace_size(name) - Get tablespace size by name
pg_tablespace_size(oid)  - Get tablespace size by OID
pg_database_size(name)   - Get database size by name
pg_database_size(oid)    - Get database size by OID
pg_table_size(text)   - Get table size (including all indexes and
toast tables) by name/
pg_table_size(oid)    - Get table size (including all indexes and
toast tables) by OID
pg_size_pretty(int8)     - Pretty print (and round) the byte size
specified (eg, 123456 = 121KB)

OK, so you went with relation as heap/index/toast only, and table as the
total of them.  I am not sure that makes sense because we usually equate
relation with table, and an index isn't a relation, really.

Do we have to use pg_object_size?  Is there a better name?  Are
indexes/toasts even objects?

Relation is not an ideal names, but I heard people talk about heap relation and index relation. Indexes and tables (and sequences) are treated in a similar way quite often. Think of ALTER TABLE example_index RENAME TO another_index. This is even less obvious. Of course in relational theory, an index would not be a relation, because an index is just implementation detail.

I don't like object_size any better, since that makes me rather think of large objects or rows as objects (object id...).

Perhaps pg_table_size should be split into pg_table_size and pg_indexes_size, where pg_indexes_size is the aggregate of all indexes on a table und pg_table_size is just table+toast+toast-index.

If noone has a better idea for pg_relation_size, I would rather keep it for consistency with the contrib module, and because it's not too far off.

Best Regards,
Michael Paesold

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to