Re: [PATCH] psql: \dn+ to show size of each schema (and \dA+ for AMs)
| От | Pavel Stehule |
|---|---|
| Тема | Re: [PATCH] psql: \dn+ to show size of each schema (and \dA+ for AMs) |
| Дата | |
| Msg-id | CAFj8pRBHO9Q9jxiWvTsD5-Z+xgPxjtjFFtyaNaA883bF3XgPwA@mail.gmail.com обсуждение исходный текст |
| Ответ на | [PATCH] psql: \dn+ to show size of each schema.. (Justin Pryzby <pryzby@telsasoft.com>) |
| Список | pgsql-hackers |
út 28. 9. 2021 v 4:46 odesílatel Justin Pryzby <pryzby@telsasoft.com> napsal:
On Fri, Sep 17, 2021 at 12:05:04PM +0200, Pavel Stehule wrote:
> I can live with the proposed patch, and I understand why ++ was
> introduced. But I am still not sure it is really user friendly. I prefer to
> extend \dA and \dn with some columns (\dA has only two columns and \dn has
> two columns too), and then we don't need special ++ variants for sizes.
> Using three levels of detail looks not too practical (more when the basic
> reports \dA and \dn) are really very simple).
You're suggesting to include the ACL+description in \dn and handler+description
and \dA.
yes
Another option is to add pg_schema_size() and pg_am_size() without shortcuts in
psql. That would avoid showing a potentially huge ACL when all one wants is
the schema size, and would serve my purposes well enough to write
| SELECT pg_namespace_size(oid), nspname FROM pg_namespace ORDER BY 1 DESC LIMIT 9;
It can work too.
I think the long ACL is a customer design issue, but can be. But the same problem is in \dt+, and I don't see an objection against this design.
Maybe I am too subjective, because 4 years I use pspg, and wide reports are not a problem for me. When the size is on the end, then it is easy to see it in pspg.
I like to see size in \dn+ report, and I like to use pg_namespace_size separately too. Both can be very practical functionality.
I think so \dt+ and \l+ is working very well now, and I am not too happy to break it (partially break it). Although the proposed change is very minimalistic.
But your example "SELECT pg_namespace_size(oid), nspname FROM pg_namespace ORDER BY 1 DESC LIMIT 9" navigates me to the second idea (that just enhances the previous). Can be nice if you can have prepared views on the server side that are +/- equivalent to psql reports, and anybody can simply write their own custom reports.
some like
SELECT schema, tablename, owner, pg_size_pretty(size) FROM pg_description.tables ORDER BY size DESC LIMIT 10
SELECT schema, owner, pg_size_pretty(size) FROM pg_description.schemas ORDER BY size DESC LIMIT 10
In the future, it can simplify psql code, and it allows pretty nice customization in any client for a lot of purposes.
Regards
Pavel
--
Justin
В списке pgsql-hackers по дате отправления: