Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-29 Thread Bruce Momjian

Patch applied.  Thanks.  /contrib/dbsize removed.  New functions:

pg_tablespace_size
pg_database_size
pg_relation_size
pg_complete_relation_size
pg_size_pretty

---

Dave Page wrote:
  
 
  -Original Message-
  From: Bruce Momjian [mailto:[EMAIL PROTECTED] 
  Sent: 06 July 2005 04:11
  To: Tom Lane
  Cc: Dave Page; Christopher Kings-Lynne; Robert Treat; Dawid 
  Kuroczko; Andreas Pflug; PostgreSQL-patches; PostgreSQL-development
  Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration
  
  Tom Lane wrote:
  
   pg_relation_size plus pg_complete_relation_size is fine.  Ship it...
  
  OK.
 
 Updated version attached.
 
 Regards, Dave.

Content-Description: dbsize.c

[ Attachment, skipping... ]

Content-Description: dbsize.patch

[ Attachment, skipping... ]

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

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-06 Thread Dave Page
 

 -Original Message-
 From: Bruce Momjian [mailto:[EMAIL PROTECTED] 
 Sent: 06 July 2005 04:11
 To: Tom Lane
 Cc: Dave Page; Christopher Kings-Lynne; Robert Treat; Dawid 
 Kuroczko; Andreas Pflug; PostgreSQL-patches; PostgreSQL-development
 Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration
 
 Tom Lane wrote:
 
  pg_relation_size plus pg_complete_relation_size is fine.  Ship it...
 
 OK.

Updated version attached.

Regards, Dave.


dbsize.c
Description: dbsize.c


dbsize.patch
Description: dbsize.patch

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-05 Thread Dave Page
 

 -Original Message-
 From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED] 
 Sent: 05 July 2005 02:39
 To: Robert Treat
 Cc: Bruce Momjian; Dave Page; Tom Lane; Dawid Kuroczko; 
 Andreas Pflug; PostgreSQL-patches; PostgreSQL-development
 Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration
 
 You are into the cycle we were in.  We discussed pg_object size (too
 vague) and pg_index_size (needs pg_toast_size too, and maybe toast
 indexes; too many functions).
  
  Yeah, I read those discussions, and think you were better 
 off then than you 
  are now, which is why I went back to it somewhat.  
 
 To be honest, the amount of effort being expended on this naming 
 discussion far outweighs the benefits.  Maybe it's time for a core 
 member to step in and just resolve it - one way or the other?

Agreed. The current names were discussed (at some length!) by Bruce  I
before I reworked the latest version of the patch. Can we just settle on
that?

Regards, Dave.

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-05 Thread Bruce Momjian
Dave Page wrote:
  You are into the cycle we were in.  We discussed pg_object size (too
  vague) and pg_index_size (needs pg_toast_size too, and maybe toast
  indexes; too many functions).
   
   Yeah, I read those discussions, and think you were better 
  off then than you 
   are now, which is why I went back to it somewhat.  
  
  To be honest, the amount of effort being expended on this naming 
  discussion far outweighs the benefits.  Maybe it's time for a core 
  member to step in and just resolve it - one way or the other?
 
 Agreed. The current names were discussed (at some length!) by Bruce  I
 before I reworked the latest version of the patch. Can we just settle on
 that?

If we go pg_table_size() and pg_relation_size(), which is object-only
and which is heap + index + toast?  I think ideally we want
pg_relation_size to be the combined one, but then we have pg_table_size
that works on indexes and toast too, and that is confusing, and we don't
want to add index and toast versions.  Or is an index a relation?  And
TOAST?

OK, how about pg_relation_size for heap/index/toast, and
pg_complete_relation_size for the combined total.

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

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-05 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes:
 If we go pg_table_size() and pg_relation_size(), which is object-only
 and which is heap + index + toast?  I think ideally we want
 pg_relation_size to be the combined one, but then we have pg_table_size
 that works on indexes and toast too, and that is confusing, and we don't
 want to add index and toast versions.  Or is an index a relation?  And
 TOAST?

All the backend code thinks so --- anything that has an entry in
pg_class is a relation.  So personally I don't find table and
relation confusing in this context.  But I can see it might be
confusing to people not familiar with PG jargon.

 OK, how about pg_relation_size for heap/index/toast, and
 pg_complete_relation_size for the combined total.

I could live with that.  Or pg_total_relation_size.

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-05 Thread Tom Lane
Bruce Momjian pgman@candle.pha.pa.us writes:
 Tom Lane wrote:
 I could live with that.  Or pg_total_relation_size.

 The problem with total, to me, is that it already is the total size of
 the heap/index/toast.  Complete has the idea of adding additional
 pieces, which I think fits best.

[ shrug ]  I don't care --- if you do, then do that.

I finally realized exactly what was bugging me about dbfile_size: it
seems to imply that we are measuring the size of one *file*, which is
under no circumstance the definition of any of these functions (see
file splitting behavior for relations exceeding 1GB).

pg_relation_size plus pg_complete_relation_size is fine.  Ship it...

regards, tom lane

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-04 Thread Dave Page
 

 -Original Message-
 From: Tom Lane [mailto:[EMAIL PROTECTED] 
 Sent: 03 July 2005 17:10
 To: Dawid Kuroczko
 Cc: Andreas Pflug; Dave Page; Bruce Momjian; 
 PostgreSQL-patches; PostgreSQL-development
 Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration 
 
 Dawid Kuroczko [EMAIL PROTECTED] writes:
  Oh, I think pg_dbfile_size is best so far.
 
 I think it's by far the ugliest suggestion yet :-(

Why? It does exactly what it says on the tin! It might not be that nice,
but it does describe what it does - and noone yet has come up with
anything less ambiguous or misleading imho.

 Andreas's suggestion of having just one function with a bool parameter
 might be a workable compromise.

Aside from the fact that's a change to the API that we had settled on,
it doesn't solve the actual problem of needing a suitable name for a
function that returns the size of a table /or/ index. pg_relation_size()
or pg_table_size() can't be used for precisely the reason they were
rejected for that purpose in the first place.

Regards, Dave.

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-04 Thread Tom Lane
Dave Page dpage@vale-housing.co.uk writes:
 Aside from the fact that's a change to the API that we had settled on,
 it doesn't solve the actual problem of needing a suitable name for a
 function that returns the size of a table /or/ index. pg_relation_size()
 or pg_table_size() can't be used for precisely the reason they were
 rejected for that purpose in the first place.

Rejected by whom?  pg_relation_size is an excellent choice for that.

regards, tom lane

---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-04 Thread Bruce Momjian
Tom Lane wrote:
 Dave Page dpage@vale-housing.co.uk writes:
  Aside from the fact that's a change to the API that we had settled on,
  it doesn't solve the actual problem of needing a suitable name for a
  function that returns the size of a table /or/ index. pg_relation_size()
  or pg_table_size() can't be used for precisely the reason they were
  rejected for that purpose in the first place.
 
 Rejected by whom?  pg_relation_size is an excellent choice for that.

We mostly tell people that table and relation are synonmous.  Though
there is a distinction, it seems error-prone to rely on that distinction
in the API.

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

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-04 Thread Dave Page
 

 -Original Message-
 From: Tom Lane [mailto:[EMAIL PROTECTED] 
 Sent: 04 July 2005 14:54
 To: Dave Page
 Cc: Dawid Kuroczko; Andreas Pflug; Bruce Momjian; 
 PostgreSQL-patches; PostgreSQL-development
 Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration 
 
 Dave Page dpage@vale-housing.co.uk writes:
  Aside from the fact that's a change to the API that we had 
 settled on,
  it doesn't solve the actual problem of needing a suitable name for a
  function that returns the size of a table /or/ index. 
 pg_relation_size()
  or pg_table_size() can't be used for precisely the reason they were
  rejected for that purpose in the first place.
 
 Rejected by whom?  pg_relation_size is an excellent choice for that.

Bruce didn't like it
(http://archives.postgresql.org/pgsql-hackers/2005-06/msg01410.php), and
you seemed to object as well
(http://archives.postgresql.org/pgsql-hackers/2005-06/msg01247.php)

Personally I'm beyond caring much now as the amount of time spent trying
to name these simple functions is wildly disproportionate the the effort
take to actually code them. I think we just need to agree there is no
perfect name and rely on the comments and docs to guide people. I think
the current names work OK, and Bruce and Dawid at least agree!

Regards, Dave.

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-04 Thread Bruce Momjian
Bruce Momjian wrote:
 Tom Lane wrote:
  Dave Page dpage@vale-housing.co.uk writes:
   Aside from the fact that's a change to the API that we had settled on,
   it doesn't solve the actual problem of needing a suitable name for a
   function that returns the size of a table /or/ index. pg_relation_size()
   or pg_table_size() can't be used for precisely the reason they were
   rejected for that purpose in the first place.
  
  Rejected by whom?  pg_relation_size is an excellent choice for that.
 
 We mostly tell people that table and relation are synonmous.  Though
 there is a distinction, it seems error-prone to rely on that distinction
 in the API.

I am starting to warm up to the idea of using relation as the combined
total.  Was that the proposal?  Are we prepared to make that distinction
in other places?

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

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-04 Thread Robert Treat
On Monday 04 July 2005 10:11, Dave Page wrote:
  -Original Message-
  From: Tom Lane [mailto:[EMAIL PROTECTED]
  Sent: 04 July 2005 14:54
  To: Dave Page
  Cc: Dawid Kuroczko; Andreas Pflug; Bruce Momjian;
  PostgreSQL-patches; PostgreSQL-development
  Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration
 
  Dave Page dpage@vale-housing.co.uk writes:
   Aside from the fact that's a change to the API that we had
 
  settled on,
 
   it doesn't solve the actual problem of needing a suitable name for a
   function that returns the size of a table /or/ index.
 
  pg_relation_size()
 
   or pg_table_size() can't be used for precisely the reason they were
   rejected for that purpose in the first place.
 
  Rejected by whom?  pg_relation_size is an excellent choice for that.

 Bruce didn't like it
 (http://archives.postgresql.org/pgsql-hackers/2005-06/msg01410.php), and
 you seemed to object as well
 (http://archives.postgresql.org/pgsql-hackers/2005-06/msg01247.php)

 Personally I'm beyond caring much now as the amount of time spent trying
 to name these simple functions is wildly disproportionate the the effort
 take to actually code them. I think we just need to agree there is no
 perfect name and rely on the comments and docs to guide people. I think
 the current names work OK, and Bruce and Dawid at least agree!


Actually I'd agree with Tom, pg_dbfile_size is ugly, and suggest to me I could 
use a filename as an argument.  ISTM that if we think that functions like 
pg_database_size and pg_tablespace_size all make sense, the natural extension 
would be functions called pg_index_size to tell us the size of an index, 
pg_table_size to tell us the size of a table (table+toast) without it's 
indexes, and some form of pg_table_plus_indexes_size for a table and its 
indexes for those that feel we need both.  I'm not sold we need a function 
that can return either an index or table size, but if so something like 
pg_object_size seems ambigious enough to work, and is future proof enough to 
handle things like materialized views when and if they arise. 

Just my .02 :-)

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-04 Thread Bruce Momjian
Robert Treat wrote:
 Actually I'd agree with Tom, pg_dbfile_size is ugly, and suggest to me I 
 could 
 use a filename as an argument.  ISTM that if we think that functions like 
 pg_database_size and pg_tablespace_size all make sense, the natural extension 
 would be functions called pg_index_size to tell us the size of an index, 
 pg_table_size to tell us the size of a table (table+toast) without it's 
 indexes, and some form of pg_table_plus_indexes_size for a table and its 
 indexes for those that feel we need both.  I'm not sold we need a function 
 that can return either an index or table size, but if so something like 
 pg_object_size seems ambigious enough to work, and is future proof enough to 
 handle things like materialized views when and if they arise. 

You are into the cycle we were in.  We discussed pg_object size (too
vague) and pg_index_size (needs pg_toast_size too, and maybe toast
indexes; too many functions).

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

---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-04 Thread Dave Page
 

 -Original Message-
 From: Robert Treat [mailto:[EMAIL PROTECTED] 
 Sent: 04 July 2005 18:21
 To: Dave Page
 Cc: Tom Lane; Dawid Kuroczko; Andreas Pflug; Bruce Momjian; 
 PostgreSQL-patches; PostgreSQL-development
 Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration
 
 
 Actually I'd agree with Tom, pg_dbfile_size is ugly, and 
 suggest to me I could 
 use a filename as an argument.  

I won't repeat Bruce's reply to you, but as an FYI, the reason Bruce
suggested pg_dbfile_size over the nicer pg_file_size is that our
instrumentation patch includes that particular function, which does
accept a filename (provided it's under $PGDATA or the log directory).
Dbfile was meant to indicate it's a database related file, rather than
some arbitrary filename.

/D


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-04 Thread Robert Treat
On Monday 04 July 2005 13:25, Bruce Momjian wrote:
 Robert Treat wrote:
  Actually I'd agree with Tom, pg_dbfile_size is ugly, and suggest to me I
  could use a filename as an argument.  ISTM that if we think that
  functions like pg_database_size and pg_tablespace_size all make sense,
  the natural extension would be functions called pg_index_size to tell us
  the size of an index, pg_table_size to tell us the size of a table
  (table+toast) without it's indexes, and some form of
  pg_table_plus_indexes_size for a table and its indexes for those that
  feel we need both.  I'm not sold we need a function that can return
  either an index or table size, but if so something like pg_object_size
  seems ambigious enough to work, and is future proof enough to handle
  things like materialized views when and if they arise.

 You are into the cycle we were in.  We discussed pg_object size (too
 vague) and pg_index_size (needs pg_toast_size too, and maybe toast
 indexes; too many functions).

Yeah, I read those discussions, and think you were better off then than you 
are now, which is why I went back to it somewhat.  

-- 
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-04 Thread Christopher Kings-Lynne

You are into the cycle we were in.  We discussed pg_object size (too
vague) and pg_index_size (needs pg_toast_size too, and maybe toast
indexes; too many functions).


Yeah, I read those discussions, and think you were better off then than you 
are now, which is why I went back to it somewhat.  


To be honest, the amount of effort being expended on this naming 
discussion far outweighs the benefits.  Maybe it's time for a core 
member to step in and just resolve it - one way or the other?


Chris


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-03 Thread Andreas Pflug

Bruce Momjian wrote:

Andreas Pflug wrote:


Dave Page wrote:







-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED] 
Sent: 02 July 2005 21:30

To: Bruce Momjian
Cc: Dave Page; PostgreSQL-patches; PostgreSQL-development
Subject: Re: [PATCHES] Dbsize backend integration


Is a new version of this patch coming?



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.


We could, taking the same logic as GRANT which uses the keyword TABLE 
for sequences and Indexes too, but it's certainly not favourable.


As far as pg_dbfile_size, do you have any other idea for a name?  To me,
it returns the size of the 'db file' associated with the
heap/index/toast.


How about pg_relation_size(oid, bool) with the second optional parameter 
 to count all additional objects too (the 'total' flag).


Regards,
Andreas


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-03 Thread Tom Lane
Dawid Kuroczko [EMAIL PROTECTED] writes:
 Oh, I think pg_dbfile_size is best so far.

I think it's by far the ugliest suggestion yet :-(

Andreas's suggestion of having just one function with a bool parameter
might be a workable compromise.

regards, tom lane

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-07-02 Thread Michael Glaesemann


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


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-06-30 Thread Greg Stark

Bruce Momjian pgman@candle.pha.pa.us writes:

 I don't think so.  I think trait and property suggests an aspect of the
 object, so saying trait/property size is saying I am talking about an
 aspect of the object, while for a heap, its size is really its size, it
 isn't an aspect of its size.

I haven't been following this discussion but, uh, does the fact that I have
absolutely no clue what pg_trait_size() or pg_property_size() would be
measuring count for anything? My best guess here is that it's for measuring
the space taken up by a column which doesn't make a lot of sense.

I think you need to think about unambiguous words that help the user
understand what the function does; words that the user might guess if they
were looking for a function to do that, whatever that is.

Not words that are sufficiently vague as to include whatever it's actually
doing but offer no clue what that is. There are an infinite number of such
words to pick and no way for the user to figure out what he or she is looking
for.

-- 
greg


---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-06-29 Thread Michael Paesold

Bruce Momjian wrote:


Dave Page wrote:



pg_relation_size(text)   - Get relation size by name/schema.name
pg_relation_size(oid)- Get relation size by OID
pg_tablespace_size(name) - Get tablespace size by name
pg_tablespace_size(oid)  - Get tablespace size by OID
pg_database_size(name)   - Get database size by name
pg_database_size(oid)- Get database size by OID
pg_table_size(text)   - Get table size (including all indexes and
toast tables) by name/schema.name
pg_table_size(oid)- Get table size (including all indexes and
toast tables) by OID
pg_size_pretty(int8) - Pretty print (and round) the byte size
specified (eg, 123456 = 121KB)



OK, so you went with relation as heap/index/toast only, and table as the
total of them.  I am not sure that makes sense because we usually equate
relation with table, and an index isn't a relation, really.

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.


Best Regards,
Michael Paesold 



---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-06-29 Thread Bruce Momjian
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

---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-06-29 Thread Andreas Pflug

Bruce Momjian wrote:




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.


I'm not really happy that all functions change their names (more 
versioning handling in pgadmin), but pg_storage_size is certainly the 
most precise name.


Regards,
Andreas


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
   (send unregister YourEmailAddressHere to [EMAIL PROTECTED])


Re: [HACKERS] [PATCHES] Dbsize backend integration

2005-06-29 Thread Tom Lane
Andreas Pflug [EMAIL PROTECTED] writes:
 I'm not really happy that all functions change their names (more 
 versioning handling in pgadmin), but pg_storage_size is certainly the 
 most precise name.

Actually, it seems excessively imprecise to me: the name conveys nothing
at all to help you remember what the definition is.  storage could
mean any of the different definitions that have been kicked around in
this thread.

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq