Bernd Helmle wrote:
These are two new functions pg_table_size() and pg_indexes_size().
This patch also changes pg_total_relation_size() to be a shorthand for
pg_table_size() + pg_indexes_size().
Attached is a test program to exercise these new functions. I
thoroughly abuse generate_series
Greg Smith g...@2ndquadrant.com writes:
The only question I'm left with after browsing the patch and staring at
the above results is whether it makes sense to expose a pg_toast_size
function. That would make the set available here capable of handling
almost every situation somebody might
Tom Lane wrote:
I'm inclined to think that table vs. index is the right level of
abstraction for these functions, and that breaking it down further than
that isn't all that helpful. We have the bottom-level information
(per-fork relation size) available for those who really want the
details.
Bernd Helmle maili...@oopsware.de writes:
Since i'm not able to finish those other things in time, i wrapped up my
existing code for this issue and came up with the attached patch, which
should implement the behavior Tom proposed. These are two new functions
pg_table_size() and
--On 22. Dezember 2009 15:11:40 +0100 Bernd Helmle maili...@oopsware.de
wrote:
Bernd, there's a basic spec if you have time to work on this.
I see if i can get some time for it during christmas vacation (its on my
radar for a longer period of time). I'm still working on this NOT NULL
2009/12/21 Tom Lane t...@sss.pgh.pa.us:
Greg Smith g...@2ndquadrant.com writes:
To answer Rafael's concerns directly: you're right that this is
confusing. pg_relation_size is always going to do what it does right
now just because of how that fits into the design of the database.
However,
--On 22. Dezember 2009 11:46:32 +0100 Cédric Villemain
cedric.villemain.deb...@gmail.com wrote:
Did you mean :
pg_table_size() = base table + toast table
pg_indexes_size() = base indexes + toast indexes
?
Since you always have a toast index automatically it makes sense to include
them
--On 21. Dezember 2009 12:02:02 -0500 Greg Smith g...@2ndquadrant.com
wrote:
Tom Lane wrote:
Perhaps invent pg_table_size() = base table + toast table + toast index
and pg_indexes_size() = all other indexes for table
giving us the property pg_table_size + pg_indexes_size =
=?ISO-8859-1?Q?C=E9dric_Villemain?= cedric.villemain.deb...@gmail.com writes:
2009/12/21 Tom Lane t...@sss.pgh.pa.us:
Perhaps invent pg_table_size() = base table + toast table + toast index
and pg_indexes_size() = all other indexes for table
giving us the property pg_table_size +
Rafael Martinez r.m.guerr...@usit.uio.no writes:
I wonder why the function pg_relation_size(text) does not take into
account the space used by toast data in a table when returning the space
used by the table.
It's not supposed to. Use pg_total_relation_size if you want a number
that includes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
Rafael Martinez r.m.guerr...@usit.uio.no writes:
I wonder why the function pg_relation_size(text) does not take into
account the space used by toast data in a table when returning the space
used by the table.
It's not supposed
--On 21. Dezember 2009 10:01:37 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
It's not supposed to. Use pg_total_relation_size if you want a number
that includes index and toast space.
I've created a C-Function a while ago that extracts the TOAST size for a
given relation. This gave me the
Rafael Martinez r.m.guerr...@usit.uio.no writes:
I am probably missing the point here, why is it not supposed to show the
size of the table(data) *without* indexes?
Because pg_relation_size is defined at the physical level of showing
one relation, where relation means a pg_class entry. If you
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bernd Helmle wrote:
--On 21. Dezember 2009 10:01:37 -0500 Tom Lane t...@sss.pgh.pa.us wrote:
It's not supposed to. Use pg_total_relation_size if you want a number
that includes index and toast space.
I've created a C-Function a while ago
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
Rafael Martinez r.m.guerr...@usit.uio.no writes:
I am probably missing the point here, why is it not supposed to show the
size of the table(data) *without* indexes?
Because pg_relation_size is defined at the physical level of
Bernd Helmle wrote:
I've created a C-Function a while ago that extracts the TOAST size for
a given relation. This gave me the opportunity to do a
pg_relation_size(oid) + pg_relation_toast_size(oid) for a given table
oid to calculate on disk data size required by a table. Maybe we
should
Greg Smith g...@2ndquadrant.com writes:
To answer Rafael's concerns directly: you're right that this is
confusing. pg_relation_size is always going to do what it does right
now just because of how that fits into the design of the database.
However, the documentation should be updated to
Tom Lane wrote:
Perhaps invent pg_table_size() = base table + toast table + toast index
and pg_indexes_size() = all other indexes for table
giving us the property pg_table_size + pg_indexes_size =
pg_total_relation_size
Right; that's exactly the way I'm computing things now, I
On Mon, Dec 21, 2009 at 5:02 PM, Greg Smith g...@2ndquadrant.com wrote:
Tom Lane wrote:
Perhaps invent pg_table_size() = base table + toast table + toast index
and pg_indexes_size() = all other indexes for table
giving us the property pg_table_size + pg_indexes_size =
Greg Stark gsst...@mit.edu writes:
On Mon, Dec 21, 2009 at 5:02 PM, Greg Smith g...@2ndquadrant.com wrote:
Right; that's exactly the way I'm computing things now, I just have to crawl
way too much catalog data to do it. I also agree that if we provide
pg_table_size, the issue of
20 matches
Mail list logo
