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

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: 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-10-31 08:26:52
Message-ID: CAPpHfdtpmjwAvSOuMvZD2YwLDLokDcapnYKm9k0Ng3vzhnjewA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Oct 29, 2017 at 12:47 AM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
wrote:

> 2017-10-28 23:35 GMT+02:00 Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>:
>
>> On Sat, Oct 28, 2017 at 3:46 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
>> wrote:
>>
>>> 2017-09-22 21:31 GMT+02:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:
>>>
>>>>
>>>>
>>>> 2017-09-22 21:12 GMT+02:00 Peter Eisentraut <
>>>> peter(dot)eisentraut(at)2ndquadrant(dot)com>:
>>>>
>>>>> On 9/22/17 09:16, Pavel Stehule wrote:
>>>>> > Example: somebody set SORT_COLUMNS to schema_name value. This is
>>>>> > nonsense for \l command
>>>>> >
>>>>> > Now, I am thinking so more correct and practical design is based on
>>>>> > special mode, activated by variable
>>>>> >
>>>>> > PREFER_SIZE_SORT .. (off, asc, desc)
>>>>> >
>>>>> > This has sense for wide group of commands that can show size. And
>>>>> when
>>>>> > size is not visible, then this option is not active.
>>>>>
>>>>> Maybe this shouldn't be a variable at all. It's not like you'll set
>>>>> this as a global preference. You probably want it for one command
>>>>> only.
>>>>> So a per-command option might make more sense.
>>>>>
>>>>
>>>> Sure, I cannot to know, what users will do. But, when I need to see a
>>>> size of objects, then I prefer the sort by size desc every time. If I need
>>>> to find some object, then I can to use a searching in pager. So in my case,
>>>> this settings will be in psqlrc. In GoodData we used years own
>>>> customization - the order by size was hardcoded and nobody reported me any
>>>> issue.
>>>>
>>>> Alexander proposed some per command option, but current syntax of psql
>>>> commands don't allows some simple parametrization. If it can be user
>>>> friendly, then it should be short. From implementation perspective, it
>>>> should be simply parsed. It should be intuitive too - too much symbols
>>>> together is not good idea.
>>>>
>>>> Maybe some prefix design - but it is not design for common people
>>>> (although these people don't use psql usually)
>>>>
>>>> '\sort size \dt ?
>>>>
>>>> \dt:sort_by_size
>>>> \dt+:sort_by_size ?
>>>>
>>>> I don't see any good design in this direction
>>>>
>>>>
>>> I though about Alexander proposal, and I am thinking so it can be
>>> probably best if we respect psql design. I implemented two command suffixes
>>> (supported only when it has sense) "s" sorted by size and "d" as descent
>>>
>>> so list of tables can be sorted with commands:
>>>
>>> \dt+sd (in this case, the order is not strict), so command
>>> \dtsd+ is working too (same \disd+ or \di+sd)
>>>
>>> These two chars are acceptable. Same principle is used for \l command
>>>
>>> \lsd+ or \l+sd
>>>
>>> What do you think about it?
>>>
>>
>> I think \lsd+ command would be another postgres meme :)
>> BTW, are you going to provide an ability to sort by name, schema?
>>
>
> It has sense only for tables - probably only \dtn "n" like name
>

In general, this approach looks good for me.
Regarding current state of patch, I'd like to see new options documented.
Also, it would be better to replace "bool sort_size" with enum assuming
there could be other sorting orders in future.

------
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 Amit Langote 2017-10-31 08:43:51 Re: path toward faster partition pruning
Previous Message Anastasia Lubennikova 2017-10-31 08:21:30 Re: WIP: Covering + unique indexes.