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 <[email protected]>, 3 Oca 2026 Cmt, 22:34 tarihinde şunu yazdı: > > On Thu, 27 Nov 2025 at 08:52, Pavel Stehule <[email protected]> wrote: > > > > > > > > st 26. 11. 2025 v 14:01 odesílatel Pavel Stehule <[email protected]> > > napsal: > >> > >> Hi > >> > >> st 26. 11. 2025 v 13:44 odesílatel Euler Taveira <[email protected]> > >> 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 maybe more than one year, and we > >> didn't find a generally acceptable design. > > > > > > https://www.postgresql.org/message-id/CAFj8pRAVV2TFHsFCV=c9aaeq7kpwgqblkowgronpan583zq...@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 very natural 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
