Re: monitoring-stats.html is too impenetrable - Mailing list pgsql-docs

From James Salsman
Subject Re: monitoring-stats.html is too impenetrable
Date
Msg-id CAD4=uZZ_5A0aouSTq_oBScYNckcsnx6Y43rrev7kSvUgXB-M4w@mail.gmail.com
Whole thread Raw
In response to Re: monitoring-stats.html is too impenetrable  (Michael Paquier <michael@paquier.xyz>)
List pgsql-docs
Thanks, Michael, but I am absolutely convinced that whether a needed
index exists or not is absolutely one of the most run-time
consequential inputs to the query planner. Also, that page is where
people look to optimize, unlike the impenetrable wall-of-text stats
page. Please correct me if I am wrong. Thank you for your
consideration.

Best regards,
Jim

On Thu, Dec 5, 2019 at 7:05 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Wed, Dec 04, 2019 at 03:29:55AM -0800, James Salsman wrote:
> > Thank you for your thoughtful reply. This might be much easier:
> >
> > How about adding another example to
> > https://www.postgresql.org/docs/11/planner-stats.html ?
>
> Not sure I see the parallel here.  This page talks about planner
> statistics, and yours about being able to find missing indexes because
> of incorrect stats.
>
> > SELECT relname, seq_scan-idx_scan AS too_much_seq,
> >    case when seq_scan-idx_scan>0 THEN 'Missing Index?' ELSE 'OK' END,
> >    pg_relation_size(relid::regclass) AS rel_size, seq_scan, idx_scan
> > FROM pg_stat_all_tables
> > WHERE schemaname='public' AND pg_relation_size(relid::regclass)>80000
> > ORDER BY too_much_seq DESC;
>
> Again.  this is a bit more complex than that.
> --
> Michael



pgsql-docs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: monitoring-stats.html is too impenetrable
Next
From: PG Doc comments form
Date:
Subject: It is recommended to add detailed description about initdb ...