Re: monitoring-stats.html is too impenetrable
От | James Salsman |
---|---|
Тема | Re: monitoring-stats.html is too impenetrable |
Дата | |
Msg-id | CAD4=uZZ_5A0aouSTq_oBScYNckcsnx6Y43rrev7kSvUgXB-M4w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: monitoring-stats.html is too impenetrable (Michael Paquier <michael@paquier.xyz>) |
Список | 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 по дате отправления: