| 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: | Whole Thread | Raw Message | 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
| 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 |