On 2019-Apr-05, Alvaro Herrera wrote:
> Looking at the current proposal, I think I like \dPn+ very much -- it
> shows the aggregated size of all partitioned tables. But I think \dP
> (without the +) is almost completely useless. I'm not really sure about
> having to add the "n" flag, but I suspect in practical use it's okay.
>
> Also, I think \dPn+ shows partitioned tables, but \dPtn+ shows exactly
> the same, so why do we have the "t" flag at all? We have \dPin+ which
> shows aggregate size, but the only way to list both tables and indexes
> is to add a pattern. I think this design was confusingly inspired by
> the "list" vs. "describe" schizoid dichotomy of \d, without actually
> getting any useful functionality in return.
>
> IMO \dP should be "list partitioned relations with their sizes", and
> \dPt "list partitioned tables with their sizes", and \dPi "list
> partitioned indexes with their sizes". If no pattern is given, list
> them all, otherwise only list those that match the pattern.
After thinking more about this, I'm having second thoughts about the +
thing. I'm now thinking that requiring the + for computing sizes is
actually a good thing, because if we change it to show all sizes
inconditionally, the command becomes unusable for users with lots of
large partitioned tables. So the submitted patch is okay in that front.
Maybe the only behavior change I'd do to the submitted patch is to have
\dP show both tables and indexes, while \dPt shows only tables and \dPi
shows only indexes. Maybe have \dPti show both tables and indexes? (
identical to \dP) That would be consistent with \d itself. Also,
compare describeFunctions, which allows multiple type specifiers to be
given.
I'm not in love with the way it handles the "n", "t" and "i" specifiers.
I think we should allow them in any order, not just if the "n" is in
cmd[2].
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services