Re: [PATCHES] Dbsize backend integration

Поиск
Список
Период
Сортировка
От Dave Page
Тема Re: [PATCHES] Dbsize backend integration
Дата
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E490E836@ratbert.vale-housing.co.uk
обсуждение исходный текст
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: falcon
Дата:
Сообщение: Re: contrib/rtree_gist into core system?
Следующее
От: Michael Glaesemann
Дата:
Сообщение: Re: [PATCHES] Dbsize backend integration