Re: [PATCH] psql: add size-based sorting options (O/o) for tables and indexes - Mailing list pgsql-hackers

Hi,
As you mentioned, this issue has remained unresolved since 2017, and I
think we need to start somewhere.
While having it as a meta-command would provide a general solution,
having size-based sorting specific to tables/indexes wouldn't prevent
a future meta-command feature from being implemented.

Best regards,

Kirill Reshke <reshkekirill@gmail.com>, 3 Oca 2026 Cmt, 22:34
tarihinde şunu yazdı:
>
> On Thu, 27 Nov 2025 at 08:52, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> >
> >
> >
> > st 26. 11. 2025 v 14:01 odesílatel Pavel Stehule <pavel.stehule@gmail.com> napsal:
> >>
> >> Hi
> >>
> >> st 26. 11. 2025 v 13:44 odesílatel Euler Taveira <euler@eulerto.com> napsal:
> >>>
> >>> On Wed, Nov 26, 2025, at 4:48 AM, M.Atıf Ceylan wrote:
> >>> > Hello,
> >>> > This patch adds two new meta-command modifiers for \dt(+) and \di(+):
> >>> >
> >>> >   - O  : sort by total relation size descending
> >>> >   - o  : sort by total relation size ascending
> >>> >
> >>>
> >>> Thanks for your contribution. Register your patch in the next commitfest [1] so
> >>> we don't loose track of it.
> >>>
> >>> I didn't look at your patch but I was wondering if a general solution isn't a
> >>> better way to add this feature. I wouldn't modify these specific psql
> >>> meta-commands, instead, I would add a new psql meta-command that defines this
> >>> property for all objects if applicable.
> >>>
> >>> \sort [ name | size [ asc | desc ] ]
> >>>
> >>> I thought about a list to be cover other sort cases too but if things starting
> >>> to be complex, it is time to write your own query.
> >>
> >>
> >> It is big question - if there should be specialized metacommand, or just variable or \pset setting
> >>
> >> it can be
> >>
> >> \set PREFERRED_ORDER size_desc
> >> \pset preffered_order size_desc
> >>
> >>
> >>>
> >>>
> >>> With a parameter, it appends the ORDER BY clause in the SQL commands executed by
> >>> psql if applicable. Without a parameter, it uses the current behavior.
> >>
> >>
> >> There were a lot of proposals related to this topic some years ago. I wrote a lot of variants of this patch
> >> Generic design is very big, and solutions like proposed are not generic :-). We talked about this feature for
maybemore than one year, and we didn't find a generally acceptable design. 
> >
> >
> > https://www.postgresql.org/message-id/CAFj8pRAVV2TFHsFCV=c9Aaeq7kPWGQBLkOwGronpAN583zqhWg@mail.gmail.com
> >
> >
> >>
> >>
> >> At the end I wrote pspg, and the sort can be done (over result) there. Using a vertical cursor (column cursor) is
verynatural and user friendly. 
> >>
> >> https://github.com/okbob/pspg
> >>
> >> Regards
> >>
> >> Pavel
> >>
> >>>
> >>>
> >>>
> >>> [1] https://commitfest.postgresql.org/57/
> >>>
> >>>
> >>> --
> >>> Euler Taveira
> >>> EDB   https://www.enterprisedb.com/
> >>>
> >>>
>
> Hi hackers.
>
> I noted that this patch cf entry has the status "Ready for committer"
> [0]. I do not think so. I see major design concerns in the proposal.
> For my 2c, I would vote for general-purpose separate \sort command or
> some suffix for meta-command as proposed by Pavel in thead from 2017.
>
> I also suggest to rename commitfest entry to describe "what" instead of "how"
>
>
> [0] https://commitfest.postgresql.org/patch/6258/
>
> --
> Best regards,
> Kirill Reshke



--
M.Atıf Ceylan