Re: [HACKERS] Dbsize backend integration

From: Michael Glaesemann <grzm(at)myrealbox(dot)com>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-patches Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] Dbsize backend integration
Date: 2005-07-03 02:45:22
Message-ID: 41B9CAEF-1804-46BC-9BDE-206EDE8DF386@myrealbox.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2005-07-03 04:19:28 Re: enable/disable trigger (Re: Fwd: [HACKERS] Open items)
Previous Message Bruce Momjian 2005-07-03 02:16:17 Re: Checkpoint cost, looks like it is WAL/CRC

Browse pgsql-patches by date

  From Date Subject
Next Message Bruce Momjian 2005-07-03 02:47:19 Re: Implementing SELECT FOR UPDATE [NOWAIT]
Previous Message Bruce Momjian 2005-07-03 02:33:05 Re: contrib/pgcrypto patch for OpenSSL 0.9.8