Re: Re: proposal - psql: possibility to specify sort for describe commands, when size is printed

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: proposal - psql: possibility to specify sort for describe commands, when size is printed
Date: 2017-03-28 07:12:26
Message-ID: CAFj8pRB+eUkP8V8oAobWx_m2V+aEsD8-KMkT1W9=B-RvEOhqTg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2017-03-27 13:59 GMT+02:00 Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>:

> On Fri, Mar 10, 2017 at 6:06 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
>
>> 2017-03-10 16:00 GMT+01:00 Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
>> :
>>
>>> On Fri, Mar 10, 2017 at 5:16 PM, Stephen Frost <sfrost(at)snowman(dot)net>
>>> wrote:
>>>
>>>> * Peter Eisentraut (peter(dot)eisentraut(at)2ndquadrant(dot)com) wrote:
>>>> > On 2/24/17 16:32, Pavel Stehule wrote:
>>>> > > set EXTENDED_DESCRIBE_SORT size_desc
>>>> > > \dt+
>>>> > > \l+
>>>> > > \di+
>>>> > >
>>>> > > Possible variants: schema_table, table_schema, size_desc,
>>>> size_asc
>>>> >
>>>> > I can see this being useful, but I think it needs to be organized a
>>>> > little better.
>>>> >
>>>> > Sort key and sort direction should be separate settings.
>>>> >
>>>> > I'm not sure why we need to have separate settings to sort by schema
>>>> > name and table name. But if we do, then we should support that for
>>>> all
>>>> > object types. I think maybe that's something we shouldn't get into
>>>> > right now.
>>>> >
>>>> > So I would have one setting for sort key = {name|size} and on for sort
>>>> > direction = {asc|desc}.
>>>>
>>>> Perhaps I'm trying to be overly cute here, but why not let the user
>>>> simply provide a bit of SQL to be put at the end of the query?
>>>>
>>>> That is, something like:
>>>>
>>>> \pset EXTENDED_DESCRIBE_ORDER_LIMIT 'ORDER BY 5 DESC LIMIT 10'
>>>>
>>>
>>> I think that's the question of usability. After all, one can manually
>>> type corresponding SQL instead of \d* commands. However, it's quite
>>> cumbersome to do this every time.
>>> I found quite useful to being able to switch between different sortings
>>> quickly. For instance, after seeing tables sorted by name, user can
>>> require them sorted by size descending, then sorted by size ascending,
>>> etc...
>>> Therefore, I find user-defined SQL clause to be cumbersome. Even psql
>>> variable itself seems to be cumbersome for me.
>>> I would propose to add sorting as second optional argument to \d*
>>> commands. Any thoughts?
>>>
>>
>> This proposal was here already - maybe two years ago. The psql command
>> parser doesn't allow any complex syntax - more - the more parameters in one
>> psql commands is hard to remember, hard to read.
>>
>
> Could you please provide a link to this discussion. Probably working with
> multiple parameters in psql commands require some rework, but that's
> definitely doable.
>

http://grokbase.com/t/postgresql/pgsql-hackers/137nt5p6s0/proposal-psql-show-longest-tables/oldest
https://www.postgresql.org/message-id/AANLkTikyaeJ0XdKDzxSvqPE8kaRRTiUQJQHwNJ8ecN2W@mail.gmail.com

>
>> With my proposal, and patch I would to cover following use case. It is
>> real case. Anytime when we used \dt+ in psql we needed sort by size desc.
>> When we should to see a size, then the top is interesting. This case is not
>> absolute, but very often, so I would to create some simple way, how to do
>> some parametrization (really simple).
>>
>
> We could combine both approaches: add parameters to psql commands and add
> psql DEFAULT_(SORT_COLUMNS|DIRECTION|LIMIT) parameters.
>

It is possible - This moment is my interest concentrated to psql settings -
the unpractical order in \dt+ irritate me :). I understand so it depends on
use-case. I worked in OLAP and still I have lot of customers with
performance incidents - the first task - show most big tables, most big
indexes.

Regards

Pavel

>
> ------
> Alexander Korotkov
> Postgres Professional: http://www.postgrespro.com
> The Russian Postgres Company
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Kechel 2017-03-28 07:51:58 Feature suggestion: Database-Security-Modules (DSM)
Previous Message Erik Rijkers 2017-03-28 06:59:25 walsender.c comments