Re: list of extended statistics on psql

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Tatsuro Yamada <tatsuro(dot)yamada(dot)tf(at)nttcom(dot)co(dot)jp>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: list of extended statistics on psql
Date: 2020-08-31 14:28:38
Message-ID: 20200831142838.GA30609@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-Aug-30, Tomas Vondra wrote:

> On Sun, Aug 30, 2020 at 12:33:29PM -0400, Alvaro Herrera wrote:

> > I wonder how to report that. Knowing that psql \-commands are not meant
> > for anything other than human consumption, maybe we can use a format()
> > string that says "built: %d bytes" when \dX+ is used (for each stat type),
> > and just "built" when \dX is used. What do people think about this?
>
> I'd use the same approach as \d+, i.e. a separate column with the size.
> Maybe that'd mean too many columns, though.

Are you thinking in one size for all stats, or a combined size? If the
former, then yes it'd be too many columns.

I'm trying to figure out what can the user *do* with that data. Can
they make the sample size smaller/bigger if the stats data is too large?
Can they do that for each individual stats type? If so, it'd make sense
to list each type's size separately.

If we do put each type in its own row -- at least "logical" row, say
string_agg(unnest(array_of_types), '\n') -- then we can put the size of each type
in a separate column with string_agg(unnest(array_of_sizes), '\n')

statname | definition | type | size
----------+-----------------+--------------------------+-----------
someobj | (a, b) FROM tab | n-distinct: built | 2000 bytes
| func-dependencies: built | 4000 bytes
another | (a, c) FROM tab | n-distint: enabled | <null>

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-08-31 14:58:11 Re: list of extended statistics on psql
Previous Message Mark Dilger 2020-08-31 14:25:21 Re: Deprecating postfix and factorial operators in PostgreSQL 13