Re: proposal - patch: psql - sort_by_size

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal - patch: psql - sort_by_size
Date: 2019-06-29 07:32:21
Message-ID: alpine.DEB.2.21.1906290901330.27352@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.

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?

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.

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

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2019-06-29 08:05:09 Re: Commitfest 2019-07, the first of five* for PostgreSQL 13
Previous Message Juanjo Santamaria Flecha 2019-06-29 06:21:37 Re: TM format can mix encodings in to_char()