Thread: Re: [PATCHES] Dbsize backend integration
> -----Original Message----- > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > Sent: 29 June 2005 12:46 > To: Dave Page > Cc: PostgreSQL-patches; PostgreSQL-development > Subject: Re: [PATCHES] Dbsize backend integration > > I have a new idea --- pg_storage_size(). I'm not against that one, but I think Tom's point is vaild. I cannot think of anything better at the moment though (maybe pg_component_size, but that's equally random) :-( Anyone else? Please? Someone? Anyone? :-) > That would do just the > toast/index/heap, and pg_relation_size() gets a total of them all, and > only works on heap, no index or toast. The totalling version (whatever it ends up being called) should definitely work on toast tables, as it is a legitimate use case to want to see the size of such a table and it's indexes, independent of the owner table. There is no need for it to work on an index though, however, it will return the right answer if it is used that way, so I think that trying to prevent it will be unecessary code that simply slows down the majority of invocations of the function for no benefit. Regards, Dave.
On Jun 30, 2005, at 5:48 PM, Dave Page wrote: >> -----Original Message----- >> From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] >> Sent: 29 June 2005 12:46 <snip /> >> I have a new idea --- pg_storage_size(). >> > > I'm not against that one, but I think Tom's point is vaild. I cannot > think of anything better at the moment though (maybe > pg_component_size, > but that's equally random) :-( > > Anyone else? Please? Someone? Anyone? :-) I'm still unclear as to what exactly is trying to be captured by the names, so I'll just throw some out and see if they're intuitive to anyone. pg_table_extensions_size() pg_table_support_size() pg_relation_extensions_size() pg_relation_support_size() pg_relation_extended_size() My two yen... if that :) Michael Glaesemann grzm myrealbox com
On 6/30/05, Dave Page <dpage@vale-housing.co.uk> wrote: > > -----Original Message----- > > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] > > Sent: 29 June 2005 12:46 > > To: Dave Page > > Cc: PostgreSQL-patches; PostgreSQL-development > > Subject: Re: [PATCHES] Dbsize backend integration > > > > I have a new idea --- pg_storage_size(). > > I'm not against that one, but I think Tom's point is vaild. I cannot > think of anything better at the moment though (maybe pg_component_size, > but that's equally random) :-( > > Anyone else? Please? Someone? Anyone? :-) pg_diskspace_size() pg_diskusage_size() pg_media_used_size() pg_allocated_size() pg_diskspace_used() Regards, Dawid PS: Yep, they aren't good...
Dawid Kuroczko wrote: > On 6/30/05, Dave Page <dpage@vale-housing.co.uk> wrote: > >>>-----Original Message----- >>>From: Bruce Momjian [mailto:pgman@candle.pha.pa.us] >>>Sent: 29 June 2005 12:46 >>>To: Dave Page >>>Cc: PostgreSQL-patches; PostgreSQL-development >>>Subject: Re: [PATCHES] Dbsize backend integration >>> >>>I have a new idea --- pg_storage_size(). >> >>I'm not against that one, but I think Tom's point is vaild. I cannot >>think of anything better at the moment though (maybe pg_component_size, >>but that's equally random) :-( >> >>Anyone else? Please? Someone? Anyone? :-) pg_df(text,text) where the $1 would be the relation name and $2 would be the type of output (human readable, bytes etc...) J > > > pg_diskspace_size() > pg_diskusage_size() > pg_media_used_size() > pg_allocated_size() > pg_diskspace_used() > > Regards, > Dawid > > PS: Yep, they aren't good... > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/
Dave Page wrote: > > That would do just the > > toast/index/heap, and pg_relation_size() gets a total of them all, and > > only works on heap, no index or toast. > > The totalling version (whatever it ends up being called) should > definitely work on toast tables, as it is a legitimate use case to want > to see the size of such a table and it's indexes, independent of the > owner table. There is no need for it to work on an index though, > however, it will return the right answer if it is used that way, so I > think that trying to prevent it will be unecessary code that simply > slows down the majority of invocations of the function for no benefit. Agreed. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073