Thread: Re: [HACKERS] Tupple statistics function

Bruce Momjian wrote:
>
> > Hi,
> >
> > I have written a small function that show how many tuples are dead
> > etc. in a specified table. Example output is:
> >
> > test=# select pgstattuple('tellers');
> > NOTICE:  physical length: 0.02MB live tuples: 200 (0.01MB, 58.59%) dead tuples: 100 (0.00MB, 29.30%) overhead:
12.11%
> >  pgstattuple
> > -------------
> >    29.296875
> > (1 row)
> >
> > Shall I add this function into contrib directory?
>
> I have been wanting this for a long time.  In fact, I wanted it linked
> to VACUUM so you could vacuum a table only if it had >X% dead tuples.
> Seems we can find a place for this in the existing commands.  Not sure
> where, though.  Ideas?

If you mean the reporting of stats how about EXPLAIN VACUMN (with other
info as well?) or EXPLAIN [VERBOSE] TABLE (see below).

In general EXPLAIN could be expanded to be a command to return an
explanation and stats of many items.
There could also be EXPLAIN that only shows fields and EXPLAIN VERBOSE
that also shows more detail such as stats (as that tends to take more
time to collect).

Examples:
EXPLAIN TABLE ttt        show table fields and indexes/rules
                VERBOSE:stats (inc tuple stats)
EXPLAIN INDEX iii        show index description and stats
EXPLAIN USER/GROUP uuu        show user name (and the users groups)
                VERBOSE:list GRANTs
EXPLAIN FUNCTION/AGGREGATE/OPERATOR fff
                show arguments of user functions
                VERBOSE:show source code

These might be useful, easier to remember, unchanging between versions
alternatives to the SELECT * from pg_ttt methods used at present.
It it probably worth checking the security options for these (not every
user should have function source code access in some business apps).

>
> --
>   Bruce Momjian                        |  http://candle.pha.pa.us
>   pgman@candle.pha.pa.us               |  (610) 853-3000
>   +  If your life is a hard drive,     |  830 Blythe Avenue
>   +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

--
This is the identity that I use for NewsGroups. Email to
this will just sit there. If you wish to email me replace
the domain with knightpiesold . co . uk (no spaces).

>>>>> "Thurstan" == Thurstan R McDougle <trmcdougle@my-deja.com> writes:

Thurstan> In general EXPLAIN could be expanded to be a command to
Thurstan> return an explanation and stats of many items.  There could
Thurstan> also be EXPLAIN that only shows fields and EXPLAIN VERBOSE
Thurstan> that also shows more detail such as stats (as that tends to
Thurstan> take more time to collect).

It would also be interesting to take everything that psql does and put
each of them into a view so that it could be queried directly.
There's no reason that the magic should reside in client-side code.
It'd also make psql much simpler. :) I mean, why is "\d" anything
other than "select * from pg_table_view;", with all the logic to
compute that table in the view code?

Unless having a view on the server is expensive.  Is a server view
expensive if nobody calls it?  I mean, it's not maintained like an
index, is it?

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

> >>>>> "Thurstan" == Thurstan R McDougle <trmcdougle@my-deja.com> writes:
>
> Thurstan> In general EXPLAIN could be expanded to be a command to
> Thurstan> return an explanation and stats of many items.  There could
> Thurstan> also be EXPLAIN that only shows fields and EXPLAIN VERBOSE
> Thurstan> that also shows more detail such as stats (as that tends to
> Thurstan> take more time to collect).
>
> It would also be interesting to take everything that psql does and put
> each of them into a view so that it could be queried directly.
> There's no reason that the magic should reside in client-side code.
> It'd also make psql much simpler. :) I mean, why is "\d" anything
> other than "select * from pg_table_view;", with all the logic to
> compute that table in the view code?
>
> Unless having a view on the server is expensive.  Is a server view
> expensive if nobody calls it?  I mean, it's not maintained like an
> index, is it?

Added to TODO:

    * Move psql backslash information into views

Makes sense.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026