Re: [HACKERS] psql \dt and table size
On Thu, Apr 7, 2011 at 3:03 PM, Bernd Helmle maili...@oopsware.de wrote: --On 28. März 2011 13:38:23 +0100 Bernd Helmle maili...@oopsware.de wrote: But I think we can just call pg_table_size() regardless in 9.0+; I believe it'll return the same results as pg_relation_size() on non-tables. Anyone see a problem with that? Hmm yeah, seems i was thinking too complicated...here is a cleaned up version of this idea. Do we consider this for 9.1 or should I add this to the CF-Next for 9.2? Since there were quite a few votes for doing this in 9.1, no dissenting votes, and it's a very small change, I went ahead and committed it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \dt and table size
--On 28. März 2011 13:38:23 +0100 Bernd Helmle maili...@oopsware.de wrote: But I think we can just call pg_table_size() regardless in 9.0+; I believe it'll return the same results as pg_relation_size() on non-tables. Anyone see a problem with that? Hmm yeah, seems i was thinking too complicated...here is a cleaned up version of this idea. Do we consider this for 9.1 or should I add this to the CF-Next for 9.2? -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \dt and table size
--On 26. März 2011 21:59:18 -0400 Robert Haas robertmh...@gmail.com wrote: But I think we can just call pg_table_size() regardless in 9.0+; I believe it'll return the same results as pg_relation_size() on non-tables. Anyone see a problem with that? Hmm yeah, seems i was thinking too complicated...here is a cleaned up version of this idea. -- Thanks Bernd psql_tablesize.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \dt and table size
On Wed, Mar 23, 2011 at 4:33 PM, Alvaro Herrera alvhe...@commandprompt.com wrote: Excerpts from Robert Haas's message of mié mar 23 17:24:59 -0300 2011: On Mon, Mar 21, 2011 at 1:44 PM, Bernd Helmle maili...@oopsware.de wrote: It stroke me today again, that \dt+ isn't displaying the acurate table size for tables, since it uses pg_relation_size() till now. With having pg_table_size() since PostgreSQL 9.0 available, i believe it would be more useful to have the total acquired storage displayed, including implicit objects (the mentioned case where it was not very useful atm was a table with a big TOAST table). I guess the threshold question for this patch is whether pg_table_size() is a more accurate table size or just a different one. Not including the toast table and index in the size is just plain wrong. Reporting the size without the toast objects is an implementation artifact that should not be done unless explicitely requested. It sounds like everyone is in agreement that we should go ahead and commit this patch, so I'll go do that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \dt and table size
On Sat, Mar 26, 2011 at 9:42 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Mar 23, 2011 at 4:33 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié mar 23 17:24:59 -0300 2011:
On Mon, Mar 21, 2011 at 1:44 PM, Bernd Helmle maili...@oopsware.de wrote:
It stroke me today again, that \dt+ isn't displaying the acurate table
size
for tables, since it uses pg_relation_size() till now. With having
pg_table_size() since PostgreSQL 9.0 available, i believe it would be more
useful to have the total acquired storage displayed, including implicit
objects (the mentioned case where it was not very useful atm was a table
with a big TOAST table).
I guess the threshold question for this patch is whether
pg_table_size() is a more accurate table size or just a different
one.
Not including the toast table and index in the size is just plain wrong.
Reporting the size without the toast objects is an implementation
artifact that should not be done unless explicitely requested.
It sounds like everyone is in agreement that we should go ahead and
commit this patch, so I'll go do that.
Err, wait a minute. This can't be quite right: showTables isn't
mutually exclusive with other options; we don't want to display the
size using pg_relation_size() when someone says:
\dts
and pg_table_size() when they say:
\dt
and pg_relation_size() when they say:
\ds
But I think we can just call pg_table_size() regardless in 9.0+; I
believe it'll return the same results as pg_relation_size() on
non-tables. Anyone see a problem with that?
Also, for clarity, the 9.0+ code should go first, like this:
if (pset.sversion = 9)
{
/* do stuff */
}
else if (pset.sversion = 81000
{
/* do different stuff */
}
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \dt and table size
Excerpts from Pavel Stehule's message of vie mar 25 02:48:49 -0300 2011: 2011/3/24 Robert Haas robertmh...@gmail.com: On Wed, Mar 23, 2011 at 4:50 PM, Pavel Stehule pavel.steh...@gmail.com wrote: can we enhance a detail for table and show more accurate numbers? table size: xxx toast size: xxx indexes size: xxx Only if we don't mind going beyond 80 columns. sure, it is on new lines That could get very long ... are you proposing something like \d++ ? -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \dt and table size
2011/3/25 Alvaro Herrera alvhe...@commandprompt.com: Excerpts from Pavel Stehule's message of vie mar 25 02:48:49 -0300 2011: 2011/3/24 Robert Haas robertmh...@gmail.com: On Wed, Mar 23, 2011 at 4:50 PM, Pavel Stehule pavel.steh...@gmail.com wrote: can we enhance a detail for table and show more accurate numbers? table size: xxx toast size: xxx indexes size: xxx Only if we don't mind going beyond 80 columns. sure, it is on new lines That could get very long ... are you proposing something like \d++ ? \d++ is good idea. I don't thing so it's necessary for detail about sizes. But it can be used for super detail: * sizes of all indexes * statistics of usage * statistics of indexes maybe - it is just idea. Pavel -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \dt and table size
On Wed, Mar 23, 2011 at 4:50 PM, Pavel Stehule pavel.steh...@gmail.com wrote: 2011/3/23 Alvaro Herrera alvhe...@commandprompt.com: Excerpts from Robert Haas's message of mié mar 23 17:24:59 -0300 2011: On Mon, Mar 21, 2011 at 1:44 PM, Bernd Helmle maili...@oopsware.de wrote: It stroke me today again, that \dt+ isn't displaying the acurate table size for tables, since it uses pg_relation_size() till now. With having pg_table_size() since PostgreSQL 9.0 available, i believe it would be more useful to have the total acquired storage displayed, including implicit objects (the mentioned case where it was not very useful atm was a table with a big TOAST table). I guess the threshold question for this patch is whether pg_table_size() is a more accurate table size or just a different one. Not including the toast table and index in the size is just plain wrong. Reporting the size without the toast objects is an implementation artifact that should not be done unless explicitely requested. +1 can we enhance a detail for table and show more accurate numbers? table size: xxx toast size: xxx indexes size: xxx Only if we don't mind going beyond 80 columns. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \dt and table size
2011/3/24 Robert Haas robertmh...@gmail.com: On Wed, Mar 23, 2011 at 4:50 PM, Pavel Stehule pavel.steh...@gmail.com wrote: 2011/3/23 Alvaro Herrera alvhe...@commandprompt.com: Excerpts from Robert Haas's message of mié mar 23 17:24:59 -0300 2011: On Mon, Mar 21, 2011 at 1:44 PM, Bernd Helmle maili...@oopsware.de wrote: It stroke me today again, that \dt+ isn't displaying the acurate table size for tables, since it uses pg_relation_size() till now. With having pg_table_size() since PostgreSQL 9.0 available, i believe it would be more useful to have the total acquired storage displayed, including implicit objects (the mentioned case where it was not very useful atm was a table with a big TOAST table). I guess the threshold question for this patch is whether pg_table_size() is a more accurate table size or just a different one. Not including the toast table and index in the size is just plain wrong. Reporting the size without the toast objects is an implementation artifact that should not be done unless explicitely requested. +1 can we enhance a detail for table and show more accurate numbers? table size: xxx toast size: xxx indexes size: xxx Only if we don't mind going beyond 80 columns. sure, it is on new lines Pavel -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \dt and table size
Hello Bernd, On 21.03.2011 18:44, Bernd Helmle wrote: Attached minor patch extends \dt to use pg_table_size() starting with PostgreSQL 9.0, not sure if we backport such changes though. It would be interesting for 9.1, however. As I already told you: I tested and it worked. The code looks correct to me. You just should send the code to a beauty farm - the wrinkles (braces) could get placed better also it could be more. :) Susanne -- Susanne Ebrecht - 2ndQuadrant PostgreSQL Development, 24x7 Support, Training and Services www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \dt and table size
On Mon, Mar 21, 2011 at 1:44 PM, Bernd Helmle maili...@oopsware.de wrote: It stroke me today again, that \dt+ isn't displaying the acurate table size for tables, since it uses pg_relation_size() till now. With having pg_table_size() since PostgreSQL 9.0 available, i believe it would be more useful to have the total acquired storage displayed, including implicit objects (the mentioned case where it was not very useful atm was a table with a big TOAST table). I guess the threshold question for this patch is whether pg_table_size() is a more accurate table size or just a different one. It could possible be confusing to display one value in that column when the server is = 9.0 and the client is = 9.1, and a different value when the server is 9.0 or the client is 9.1. On the other hand, it's clear that there are several people in favor of this change, so maybe we should just go ahead and do it. Not sure. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \dt and table size
Excerpts from Robert Haas's message of mié mar 23 17:24:59 -0300 2011: On Mon, Mar 21, 2011 at 1:44 PM, Bernd Helmle maili...@oopsware.de wrote: It stroke me today again, that \dt+ isn't displaying the acurate table size for tables, since it uses pg_relation_size() till now. With having pg_table_size() since PostgreSQL 9.0 available, i believe it would be more useful to have the total acquired storage displayed, including implicit objects (the mentioned case where it was not very useful atm was a table with a big TOAST table). I guess the threshold question for this patch is whether pg_table_size() is a more accurate table size or just a different one. Not including the toast table and index in the size is just plain wrong. Reporting the size without the toast objects is an implementation artifact that should not be done unless explicitely requested. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \dt and table size
2011/3/23 Alvaro Herrera alvhe...@commandprompt.com: Excerpts from Robert Haas's message of mié mar 23 17:24:59 -0300 2011: On Mon, Mar 21, 2011 at 1:44 PM, Bernd Helmle maili...@oopsware.de wrote: It stroke me today again, that \dt+ isn't displaying the acurate table size for tables, since it uses pg_relation_size() till now. With having pg_table_size() since PostgreSQL 9.0 available, i believe it would be more useful to have the total acquired storage displayed, including implicit objects (the mentioned case where it was not very useful atm was a table with a big TOAST table). I guess the threshold question for this patch is whether pg_table_size() is a more accurate table size or just a different one. Not including the toast table and index in the size is just plain wrong. Reporting the size without the toast objects is an implementation artifact that should not be done unless explicitely requested. +1 can we enhance a detail for table and show more accurate numbers? table size: xxx toast size: xxx indexes size: xxx Regards Pavel Stehule -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \dt and table size
2011/3/22 David Fetter da...@fetter.org: +1 for fixing this behavior in 9.1. -1 for changing in 9.0, as the change in behavior mid-release will cause more confusion than the incomplete accounting does. Idem. Cheers, David. On Mon, Mar 21, 2011 at 06:44:51PM +0100, Bernd Helmle wrote: It stroke me today again, that \dt+ isn't displaying the acurate table size for tables, since it uses pg_relation_size() till now. With having pg_table_size() since PostgreSQL 9.0 available, i believe it would be more useful to have the total acquired storage displayed, including implicit objects (the mentioned case where it was not very useful atm was a table with a big TOAST table). Attached minor patch extends \dt to use pg_table_size() starting with PostgreSQL 9.0, not sure if we backport such changes though. It would be interesting for 9.1, however. -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql \dt and table size
+1 for fixing this behavior in 9.1. -1 for changing in 9.0, as the change in behavior mid-release will cause more confusion than the incomplete accounting does. Cheers, David. On Mon, Mar 21, 2011 at 06:44:51PM +0100, Bernd Helmle wrote: It stroke me today again, that \dt+ isn't displaying the acurate table size for tables, since it uses pg_relation_size() till now. With having pg_table_size() since PostgreSQL 9.0 available, i believe it would be more useful to have the total acquired storage displayed, including implicit objects (the mentioned case where it was not very useful atm was a table with a big TOAST table). Attached minor patch extends \dt to use pg_table_size() starting with PostgreSQL 9.0, not sure if we backport such changes though. It would be interesting for 9.1, however. -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- David Fetter da...@fetter.org http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
