DBSize backend integration - Mailing list pgsql-hackers

From Dave Page
Subject DBSize backend integration
Date
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E490E718@ratbert.vale-housing.co.uk
Whole thread Raw
Responses Re: DBSize backend integration
List pgsql-hackers
The following functions are currently in contrib/dbsize. As Bruce has
suggested, we should discuss which functions should or shouldn't be
moved into the backend, and which should be renamed.

int8 pg_database_size(oid)
int8 database_size(name)

Both return the database size in bytes, the first by oid, the second by
name. Michael has indicated that he finds the second form useful, and we
already use the first form in pgAdmin. Either form can emulate the other
with a simple subselect. I would suggest that the second form be renamed
to match the first for consistency, if it is decided that they be kept.

int8 pg_tablespace_size(oid)

This returns the size of the tablespace in bytes. If both forms of the
database_size function are included, then a 'by name' equivalent should
probably be added.

int8 pg_relation_size(oid)
int8 relation_size(text)

As per *database_size(*), but per relation.

text pg_size_pretty(int8)

Converts a size in bytes to B/KB/MB/GB etc.

int8 indexes_size(text)

Returns the total size of the indexes on the named relation. A
convenience function with questionable usefulness (IMO). Currently
implemented as an SQL function.

int8 total_relation_size(text)

Returns relation_size(text) + indexes_size(text) +
relation_size(text->toast tables). As per indexes_size, currently
implemented as an SQL function.

setof record relation_size_components(text)

A 'view' returning the sizes of each component of the named relation
(relation, indexes, toast tables etc). Broken at present because it
isn't schema aware.


My personal view is that pg_database_size, pg_relation_size and
pg_tablespace_size, as well as pg_size_pretty should be included. If
others consider that the by name versions are also useful, then they
should be included, but renamed for consistency. The other three
functions should be dropped IMO.

Thoughts?

Regards, Dave.


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Server instrumentation patch
Next
From: Bruce Momjian
Date:
Subject: Re: DBSize backend integration