MIME-Version: 1.0
References: <157458791863.7229.15011272113637426410@wrigleys.postgresql.org>
 <20191125012036.GC37821@paquier.xyz>
 <CAD4=uZZRYy8bkedyRipiu0Yp0ZTUszUg6RUTuNnmSs6Y1i2-fA@mail.gmail.com>
 <20191206030445.GI121835@paquier.xyz>
In-Reply-To: <20191206030445.GI121835@paquier.xyz>
From: James Salsman <jsalsman@gmail.com>
Date: Thu, 5 Dec 2019 19:14:14 -0800
Message-ID: 
 <CAD4=uZZ_5A0aouSTq_oBScYNckcsnx6Y43rrev7kSvUgXB-M4w@mail.gmail.com>
Subject: Re: monitoring-stats.html is too impenetrable
To: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-docs@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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