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 по дате отправления:

Предыдущее
От: "Drouvot, Bertrand"
Дата:
Сообщение: Re: [BUG] failed assertion in EnsurePortalSnapshotExists()
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: POC: Cleaning up orphaned files using undo logs