Re: proposal - psql - show longest tables

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal - psql - show longest tables
Date: 2013-07-22 19:32:34
Message-ID: CAFj8pRBsSgQUa+uNOwYSTYZN+muqjcOVJQi+199zMKO9eY8mfg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2013/7/22 Merlin Moncure <mmoncure(at)gmail(dot)com>:
> On Mon, Jul 22, 2013 at 2:03 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Sun, Jul 21, 2013 at 12:47 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>>> Hello all
>>>
>>> I very often use a little bit adjusted psql system queries to
>>> detection TOP N sized tables. I am thinking so it can be useful for
>>> all users
>>>
>>> I propose a few new commands
>>>
>>> \dts [N|size] ... show N largest tables | show tables larger than size
>>> ordered by size
>>> \dis [N|size] ... show N largest indexes | show indexes larger than
>>> size ordered by size
>>> \dtst [N|size] ... show N largest total size | show tables where total
>>> size is larger than size ordered by total size
>>> \dtr [N] ... show N largest tables (ordered by rows)
>>>
>>> example:
>>>
>>> \dts 10 --- top 10 tables ordered by size
>>> \dts 10MB -- tables larger than 10MB ordered by size
>>>
>>> Schema | Name | Type | Owner | Size
>>> --------+-------------+-------+-------------+-------+-------------
>>> public | eshop_users | table | eshop_owner | 16 kB
>>> public | zamestnanci | table | eshop_owner | 16 kB
>>>
>>> What do you think about this proposal? Comments, notes?
>>
>> I think our \d commands are in inscrutable morass of indecipherable
>> gobbledygook as it is, and this is only one more step down the road to
>> complete insanity. :-(
>>
>> Rather than just continuing to add more imposible-to-remember syntax,
>> we really need a better design here.
>
> These type of administrative tasks should be implemented as stored
> procedures or functions, not enhancements to psql. That way non-psql
> clients can leverage them and you can integrate them to other queries.
> Another advantage is that they can be implemented as extension.
>
> SELECT * from top5();
>

Is not a problem for any advanced user write these queries.

But it is hard use a parametrized query inside psql.

> Is a little more of a pain to type. But with my psql-fu I can cut
> that down with \i if I'm so inclined.

you cannot use parameters - then I have to have prepared files like
top10, top20, ... what is not too friendly

Regards

Pavel

>
> merlin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-07-22 19:39:56 RangeTblEntry.joinaliasvars representation change
Previous Message Andrew Gierth 2013-07-22 19:31:16 Re: Review: UNNEST (and other functions) WITH ORDINALITY