Re: list of extended statistics on psql - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: list of extended statistics on psql
Date
Msg-id 20200831142838.GA30609@alvherre.pgsql
Whole thread Raw
In response to Re: list of extended statistics on psql  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: list of extended statistics on psql  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: list of extended statistics on psql  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List 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



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: Deprecating postfix and factorial operators in PostgreSQL 13
Next
From: Tom Lane
Date:
Subject: Re: list of extended statistics on psql