Re: Dbsize backend integration

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>
Cc: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Dbsize backend integration
Date: 2005-06-29 01:16:20
Message-ID: 200506290116.j5T1GKn20608@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Dave Page wrote:
> The attached patch integrates dbsize functions into the backend, as per
> discussion on -hackers. The following functions are included:
>
> pg_relation_size(text) - Get relation size by name/schema.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/schema.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)
>
> This is based on the dbsize contrib module, and previous patches from
> Andreas Pflug and Ed L.
>
> The dbsize module should be removed once this is applied, and the
> catalog version incremented as I haven't included that in the patch.

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?

Of course, these issues are all minor, but we might as well get them
resolved.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2005-06-29 01:47:19 Re: For review: Server instrumentation patch
Previous Message Jim C. Nasby 2005-06-29 00:23:49 Re: [HACKERS] Problem with dblink regression test - FIXED

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2005-06-29 01:24:03 Re: slight changes to gist.sgml
Previous Message Jim C. Nasby 2005-06-29 00:23:49 Re: [HACKERS] Problem with dblink regression test - FIXED