:
-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
-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
-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
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
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
Tom Lane wrote:
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
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
Tom Lane wrote:
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
-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
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
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
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.
-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
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
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
-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
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
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.
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
On 7/3/05, Andreas Pflug [EMAIL PROTECTED] 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
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
Is a new version of this patch coming?
---
Bruce Momjian wrote:
Dave Page wrote:
-Original Message- From: Bruce Momjian
[mailto:[EMAIL PROTECTED] Sent: Wed 6/29/2005 2:16 AM To: Dave
Page Cc:
-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
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,
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
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
-Original Message-
From: Dawid Kuroczko [mailto:[EMAIL PROTECTED]
Sent: 30 June 2005 22:21
To: Dave Page
Cc: PostgreSQL-development
Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration
On 6/30/05, Dave Page dpage@vale-housing.co.uk wrote:
-Original Message
Dave Page dpage@vale-housing.co.uk writes:
I've not been following the thread closely, so maybe this was already
proposed and rejected, but what about:
[4 functions]
That moves the goal posts somewhat.
Fair enough. The two you described are OK by me.
regards, tom
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
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
On Jun 30, 2005, at 5:48 PM, Dave Page wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 29 June 2005 12:46
snip /
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
-Original Message-
From: Michael Glaesemann [mailto:[EMAIL PROTECTED]
Sent: 30 June 2005 10:01
To: Dave Page
Cc: PostgreSQL-patches; PostgreSQL-development
Subject: Re: [PATCHES] Dbsize backend integration
I'm still unclear as to what exactly is trying to be captured by the
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? :-)
Maybe pg_trait_size() or
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 30 June 2005 10:29
To: Bruce Momjian; Dave Page
Cc: PostgreSQL-patches; PostgreSQL-development
Subject: Re: [PATCHES] Dbsize backend integration
Maybe pg_trait_size() or pg_property_size() will do?
I
Dave Page dpage@vale-housing.co.uk writes:
Thanks Michael. We have 2 functions - 1 returns the on disk size of a
table or index without any additional parts such as indexes or toast
tables. The other function returns the total on disk size of a table and
all associated indexes and toast tables
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: 30 June 2005 14:41
To: Dave Page
Cc: Michael Glaesemann; PostgreSQL-patches; PostgreSQL-development
Subject: Re: [PATCHES] Dbsize backend integration
Dave Page dpage@vale-housing.co.uk writes:
Thanks Michael.
On 6/30/05, Dave Page dpage@vale-housing.co.uk wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
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
Dawid Kuroczko wrote:
On 6/30/05, Dave Page dpage@vale-housing.co.uk wrote:
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: 29 June 2005 12:46
To: Dave Page
Cc: PostgreSQL-patches; PostgreSQL-development
Subject: Re: [PATCHES] Dbsize backend integration
I have a
Dave Page wrote:
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
[EMAIL PROTECTED] wrote:
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? :-)
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
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) -
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Wed 6/29/2005 2:16 AM
To: Dave Page
Cc: PostgreSQL-patches; PostgreSQL-development
Subject: Re: [PATCHES] Dbsize backend integration
OK, so you went with relation as heap/index/toast only, and table as the
total
Dave Page wrote:
-Original Message- From: Bruce Momjian
[mailto:[EMAIL PROTECTED] Sent: Wed 6/29/2005 2:16 AM To: Dave
Page Cc: PostgreSQL-patches; PostgreSQL-development Subject: Re:
[PATCHES] Dbsize backend integration
OK, so you went with relation as heap/index/toast only,
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
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
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
Dave Page wrote:
The attached patch integrates dbsize functions into the backend, as per
discussion on -hackers. The following functions are included:
pg_relation_size(text) - Get relation size by name/schema.name
pg_relation_size(oid)- Get relation size by OID
47 matches
Mail list logo
