Re: [PATCHES] Dbsize backend integration - Mailing list pgsql-hackers

From Dave Page
Subject Re: [PATCHES] Dbsize backend integration
Date
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E490E836@ratbert.vale-housing.co.uk
Whole thread Raw
Responses Re: [PATCHES] Dbsize backend integration  (Michael Glaesemann <grzm@myrealbox.com>)
Re: [PATCHES] Dbsize backend integration  (Dawid Kuroczko <qnex42@gmail.com>)
Re: [PATCHES] Dbsize backend integration  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers

> -----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.

pgsql-hackers by date:

Previous
From: falcon
Date:
Subject: Re: contrib/rtree_gist into core system?
Next
From: Michael Glaesemann
Date:
Subject: Re: [PATCHES] Dbsize backend integration