Re: monitoring-stats.html is too impenetrable

From: James Salsman <jsalsman(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: pgsql-docs(at)lists(dot)postgresql(dot)org
Subject: Re: monitoring-stats.html is too impenetrable
Date: 2019-12-06 03:14:14
Message-ID: CAD4=uZZ_5A0aouSTq_oBScYNckcsnx6Y43rrev7kSvUgXB-M4w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)paquier(dot)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

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message PG Doc comments form 2019-12-06 09:22:01 It is recommended to add detailed description about initdb ...
Previous Message Michael Paquier 2019-12-06 03:04:45 Re: monitoring-stats.html is too impenetrable