Re: [HACKERS] Dbsize backend integration
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] Dbsize backend integration |
Дата | |
Msg-id | 200506291201.j5TC1aT01826@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Dbsize backend integration ("Michael Paesold" <mpaesold@gmx.at>) |
Ответы |
Re: [HACKERS] Dbsize backend integration
|
Список | pgsql-patches |
Michael Paesold wrote: > > Do we have to use pg_object_size? Is there a better name? Are > > indexes/toasts even objects? > > Relation is not an ideal names, but I heard people talk about heap relation > and index relation. Indexes and tables (and sequences) are treated in a > similar way quite often. Think of ALTER TABLE example_index RENAME TO > another_index. This is even less obvious. Of course in relational theory, > an index would not be a relation, because an index is just implementation > detail. > > I don't like object_size any better, since that makes me rather think of > large objects or rows as objects (object id...). > > Perhaps pg_table_size should be split into pg_table_size and > pg_indexes_size, where pg_indexes_size is the aggregate of all indexes on a > table und pg_table_size is just table+toast+toast-index. > > If noone has a better idea for pg_relation_size, I would rather keep it for > consistency with the contrib module, and because it's not too far off. Yea, but then we have toast and we would need another name. I suggested pg_storage_size() because it relates to a storage unit (index, toast, etc), and not a real object or relation. -- 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
В списке pgsql-patches по дате отправления: