Re: proposal - patch: psql - sort_by_size

Hi

so 29. 6. 2019 v 10:19 odesílatel Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
napsal:

>
>
> so 29. 6. 2019 v 9:32 odesílatel Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
> napsal:
>
>>
>> Hello Pavel,
>>
>> > \set SORT_BY_SIZE on
>> > \dt -- sorted by schema, name (size is not calculated and is not
>> visible)
>> > \dt+ -- sorted by size
>>
>> Patch applies cleanly, compiles, runs. "make check" ok. doc build ok.
>>
>> There are no tests. Some infrastructure should be in place so that such
>> features can be tested, eg so psql-specific TAP tests. ISTM that there
>> was
>> a patch submitted for that, but I cannot find it:-( Maybe it is combined
>> with some other patch in the CF.
>>
>
> It is not possible - the size of relations is not stable (can be different
> on some platforms), and because showing the size is base of this patch, I
> cannot to write tests. Maybe only only set/unset of variable.
>
>
>>
>> I agree that the simpler the better for such a feature.
>>
>> ISTM that the fact that the option is ignored on \dt is a little bit
>> annoying. It means that \dt and \dt+ would not show their results in the
>> same order. I understand that the point is to avoid the cost of computing
>> the sizes, but if the user asked for it, should it be done anyway?
>>
>
> It was one objection against some previous patches. In this moment I don't
> see any wrong on different order between \dt and \dt+. When column "size"
> will be displayed, then ordering of report will be clean.
>
> I am not strongly against this - implementation of support SORT_BY_SIZE
> for non verbose mode is +/- few lines more. But now (and it is just my
> opinion and filing, nothing more), I think so sorting reports by invisible
> columns can be messy. But if somebody will have strong different option on
> this point, I am able to accept it. Both variants can have some sense, and
> some benefits - both variants are consistent with some rules (but cannot be
> together).
>
>
>> I'm wondering whether it would make sense to have a slightly more generic
>> interface allowing for more values, eg:
>>
>> \set DESCRIPTION_SORT "name"
>> \set DESCRIPTION_SORT "size"
>>
>> Well, possibly this is a bad idea, so it is really a question.
>>
>
> We was at this point already :). If you introduce this, then you have to
> support combinations schema_name, name_schema, size, schema_size, ...
>
> My goal is implementation of most common missing alternative into psql -
> but I would not to do too generic implementation - it needs more complex
> design (and UI), and I don't think so people use it. SORT_BY_SIZE (on/off)
> looks simply, and because (if will not be changed) it has not impact on non
> verbose mode, then it can be active permanently (and if not, it is not
> mental hard work to set it).
>
> I think so more generic solution needs interactive UI. Now I working on
> vertical cursor support for pspg https://github.com/okbob/pspg. Next step
> will be sort by column under vertical cursor. So, I hope, it can be good
> enough for simply sorting by any column of report (but to be user friendly,
> it needs interactive UI). Because not everywhere is pspg installed, I would
> to push some simple solution (I prefer simplicity against generic) to psql.
>
>
>
>>
>> + Setting this variable to <literal>on</literal> causes so results of
>> + <literal>\d*</literal> commands will be sorted by size, when size
>> + is displayed.
>>
>> Maybe the simpler: "Setting this variable on sorts \d* outputs by size,
>> when size is displayed."
>>
>
I used this text in today patch

Regards

Pavel

>
>> ISTM that the documentation is more generic than reality. Does it work
>> with \db+? It seems to work with \dm+.
>>
>> On equality, ISTM it it should sort by name as a secondary criterion.
>>
>> I tested a few cases, although not partitioned tables.
>>
>
> Thank you - I support now relations (tables, indexes, ), databases, and
> tablespaces. The column size is displayed for data types report, but I am
> not sure about any benefit in this case.
>
> Regards
>
> Pavel
>
>
>> --
>> Fabien.
>>
>>
>>