eSQL-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
> -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: [HACK
Tom Lane wrote:
> Bruce Momjian 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 fit
Bruce Momjian 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 ca
Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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
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
> >
> -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: [HACK
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.
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,
> > t
> -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] Dbsiz
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
evelopment
> > Subject: Re: [HACKERS] [PATCHES] Dbsize backend integration
> >
> > "Dave Page" writes:
> > > Aside from the fact that's a change to the API that we had
> >
> > settled on,
> >
> > > it doesn't solve
Bruce Momjian wrote:
> Tom Lane wrote:
> > "Dave Page" 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()
> >
> -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 integra
Tom Lane wrote:
> "Dave Page" 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 use
"Dave Page" 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
> -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 in
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
---
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_s
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
I
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
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 integr
Bruce Momjian 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 followi
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 re
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 i
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 quit
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) - Ge
28 matches
Mail list logo
