Re: [HACKERS] DBSize backend integration

2005-06-26 Thread Michael Paesold
Dave Page wrote: -Original Message- From: Andrew Dunstan [mailto:[EMAIL PROTECTED] Sent: 24 June 2005 21:12 To: Bruce Momjian Cc: Dave Page; PostgreSQL-development Subject: Re: [HACKERS] DBSize backend integration Bruce Momjian wrote: So drop total_relation_size

Re: [HACKERS] DBSize backend integration

2005-06-26 Thread Bruce Momjian
Michael Paesold wrote: relation_size_components() depends on total_relation_size() (which I have to agree could be useful). I think relation_size_components() is unecessary though - it looks like it was designed to show a summary rather than as a view to be used by other clients (if that

Re: [HACKERS] DBSize backend integration

2005-06-26 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes: Can someone come up with a better name than total_relation_size(), because we already have relation_size()? The problem is that in the first case, relation means the relation/indexes/toast, and in the second it is just the heap. Should we call

Re: [HACKERS] DBSize backend integration

2005-06-25 Thread Andreas Pflug
Dave Page wrote: -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 24 June 2005 21:07 To: Dave Page Cc: PostgreSQL-development Subject: Re: [HACKERS] DBSize backend integration So drop total_relation_size(), relation_size_components

Re: [HACKERS] DBSize backend integration

2005-06-25 Thread Bruce Momjian
Andreas Pflug wrote: [from memory] the relation_components function adds components in a questionable way, e.g. counting on index on the toast table as index. To me, that's internal implementation detail, and should be counted as toast table size too. Agreed. The user doesn't

Re: [HACKERS] DBSize backend integration

2005-06-24 Thread Bruce Momjian
Dave Page wrote: 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

Re: [HACKERS] DBSize backend integration

2005-06-24 Thread Dave Page
-Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 24 June 2005 20:45 To: Dave Page Cc: PostgreSQL-development Subject: Re: [HACKERS] DBSize backend integration My personal view is that pg_database_size, pg_relation_size and pg_tablespace_size, as well

Re: [HACKERS] DBSize backend integration

2005-06-24 Thread Bruce Momjian
Dave Page wrote: -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 24 June 2005 20:45 To: Dave Page Cc: PostgreSQL-development Subject: Re: [HACKERS] DBSize backend integration My personal view is that pg_database_size, pg_relation_size

Re: [HACKERS] DBSize backend integration

2005-06-24 Thread Andrew Dunstan
Bruce Momjian wrote: So drop total_relation_size(), relation_size_components(), and what else? But these answer easily the question I see most asked - how much space in total does the relation occupy. I'd like to see at least one of these, properly named and fixed w.r.t. schemas.

Re: [HACKERS] DBSize backend integration

2005-06-24 Thread Dave Page
-Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED] Sent: 24 June 2005 21:07 To: Dave Page Cc: PostgreSQL-development Subject: Re: [HACKERS] DBSize backend integration So drop total_relation_size(), relation_size_components(), and what else

Re: [HACKERS] DBSize backend integration

2005-06-24 Thread Dave Page
-Original Message- From: Andrew Dunstan [mailto:[EMAIL PROTECTED] Sent: 24 June 2005 21:12 To: Bruce Momjian Cc: Dave Page; PostgreSQL-development Subject: Re: [HACKERS] DBSize backend integration Bruce Momjian wrote: So drop total_relation_size