:
-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
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
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
-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.
] 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
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
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
: 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 of them. I am not sure that makes sense because we usually equate
relation with table, and an index isn't a relation
-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
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: 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
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
-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
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
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
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) -
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
If dbsize is being moved from contrib to the backend, it should be moved
in in its entirety ...
On Tue, 21 Jun 2005, Bruce Momjian wrote:
This version is being removed from the patches queue because it does not
address how to handle existing dbsize functions not moved into the main
server.
Andreas Pflug wrote:
As a start for a bunch of instrumentation functions that should be
included in the backend as discussed previously, here are the dbsize
functions. The dbsize.c file should go to the usual place,
src/backend/utils/adt.
How does this related to /contrib/dbsize? You have
As a start for a bunch of instrumentation functions that should be
included in the backend as discussed previously, here are the dbsize
functions. The dbsize.c file should go to the usual place,
src/backend/utils/adt.
Regards,
Andreas
? GNUmakefile
? config.log
? config.status
?
38 matches
Mail list logo
