Re: proposal - patch: psql - sort_by_size

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."
>
> 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.
>
>
>