Re: [PATCHES] Dbsize backend integration

Поиск
Список
Период
Сортировка
От Michael Glaesemann
Тема Re: [PATCHES] Dbsize backend integration
Дата
Msg-id 41B9CAEF-1804-46BC-9BDE-206EDE8DF386@myrealbox.com
обсуждение исходный текст
Ответ на Re: [PATCHES] Dbsize backend integration  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
On Jul 3, 2005, at 8:35 AM, Bruce Momjian wrote:

> Andreas Pflug wrote:
>
>> Dave Page wrote:
>>
>>> Yup, attached. Per our earlier conversation, pg_dbfile_size() now
>>> returns the size of a table or index, and pg_relation_size()
>>> returns the
>>> total size of a relation and all associated indexes and toast tables
>>> etc.
>>>
>>
>> pg_relation_size's name is quite unfortunate, since the 8.0 contrib
>> function does something different. And pg_dbfile_size sounds
>> misleading,
>> suggesting it takes a filename or relfilenode as parameter.
>>
>
> Hmm.  I don't see how we can call it pg_table_size because people
> think
> of tables and indexes, while relation has a more inclusive suggestion.

I'm not familiar enough with the backend code to know if there's a
semantic difference between how relation and table are treated, so my
line of reasoning may be flawed. However, I try to use the term
relation when I'm discussing things at a logical level--the
predicates the data represents. Indexes and toast tables are
implementation details, separate from the predicates the relation
represents.

The distinction between table and relation is very small, and using
both pg_table_size and pg_relation_size but with different meanings
is going to have people dependent on the documentation to remember
the difference; pg_table_size and pg_relation_size both have the same
meaning to me: the size of the table or index. I'd lean towards
pg_table_size because this has a looser meaning that more easily
includes indexes. An index doesn't really contain predicates and one
doesn't store things in them directly.

I think what's needed is a term that expresses the more inclusive or
implementation-specific nature of the function that returns table +
indexes + toast tables + kitchen sink.

pg_tableall_size? pg_tablefull_size? pg_tableplus_size?
pg_tableandmore_size? pg_tableimplementation_size?
pg_tablekitchensink_size? ;)

I recognize the desire to have a relatively short name for the
functions, but perhaps a longer one is needed to capture the
distinction between the two. (Though it's kind of frustrating that
none of us have been able to hit on a term that accurately and
succinctly describes it.)

Michael Glaesemann
grzm myrealbox com


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Checkpoint cost, looks like it is WAL/CRC
Следующее
От: Neil Conway
Дата:
Сообщение: Re: bug in ALTER TABLE / TYPE