Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1icUkD-0005hb-BG for pgsql-docs@arkaria.postgresql.org; Wed, 04 Dec 2019 13:31:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1icUkC-0005Lb-5e for pgsql-docs@arkaria.postgresql.org; Wed, 04 Dec 2019 13:31:04 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1icSrD-0008Ab-U2 for pgsql-docs@lists.postgresql.org; Wed, 04 Dec 2019 11:30:12 +0000 Received: from mail-ot1-x341.google.com ([2607:f8b0:4864:20::341]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1icSrA-0006c4-I4 for pgsql-docs@lists.postgresql.org; Wed, 04 Dec 2019 11:30:11 +0000 Received: by mail-ot1-x341.google.com with SMTP id 66so5980800otd.9 for ; Wed, 04 Dec 2019 03:30:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5ESO4B+J/08QmcvEhBBJ5QQqu3EZmSi9M0NWKzgtAvk=; b=pMkpxSOxw9rc/v9YSYHReKGV6BrIDWT+6vp/lICXJF7V2TB+0yBuWA+CiiDgwhWtgg +wKzQ7KSpO2kVXw4J5HvXkwfppfYzhrk/gnHrJrxNRJM+1EXBQ3mHjR1ngNgjvXdneGq 8g9FcskacIW3wp8E1LCX1OhWway8HLU6iNAP0kB4zL+ILX5ZnZonN90s9WZZGvWyClk4 3H5tEYBbua/8KNjp/vKzk2LJrpfkMSkR3nguNjFyzCMVKe2binR9OkALSifyfwUQ7Zda qhhPT+sjZUfv+Mjbt3onDo1Mx/S+PUE05tj0SH73MOk66NDRyoNHy5GvIphNLEvr8V55 uUOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5ESO4B+J/08QmcvEhBBJ5QQqu3EZmSi9M0NWKzgtAvk=; b=CqeUqHcXlDjt6xEORUiAgYqSXyIHsn24EmHseMZikhPPkm5n9CGCQfCmPvZG3tDJO3 8ZPz4X1wyMJrDgaprHBPS3kObAOhsvhj1GkADKwYoAZjaU+puAABg3KLFysOQDR3pmd5 cy7zlSm1OeR95ucmUUaWrci2q4Il2HzB+UEszMDbM/lLXdSL3FNRPM8+i0mbcoYuuR17 9zjdEvAOZqm2/vinl+NsSVrawFsLxMIH6/Adhh8YnyFITDs2VC49SVqj1M1/CJswkTPg 6rUQYBTNRcDget/OdoAmXZR4Y7TWL5c90ePpCVvUPE+yF/AwydfgEbr5r4HNMxyHfc6t CaOw== X-Gm-Message-State: APjAAAXD78VW3bHGHdgSNfWLuQ/ly3xVTbFkeCHrEwwAJkc4tU4z32ZR v0/F54Jw8Ha2hTiQulD5e03aNK+83V4nvjcCvJ43NxZNvew= X-Google-Smtp-Source: APXvYqyEeQlgjKXi6k8Dty6bKyBNqOas9KHwBrNSXsjnbGQW0ZMVJ5nmwUR+Tw94VjXx+AMKLkQf2iHNBqUs1G+6gWs= X-Received: by 2002:a9d:5d10:: with SMTP id b16mr2071177oti.250.1575459006440; Wed, 04 Dec 2019 03:30:06 -0800 (PST) MIME-Version: 1.0 References: <157458791863.7229.15011272113637426410@wrigleys.postgresql.org> <20191125012036.GC37821@paquier.xyz> In-Reply-To: <20191125012036.GC37821@paquier.xyz> From: James Salsman Date: Wed, 4 Dec 2019 03:29:55 -0800 Message-ID: Subject: Re: monitoring-stats.html is too impenetrable To: Michael Paquier Cc: pgsql-docs@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Michael, 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 ? 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; The rationale and ideas for how to introduce the example at https://www.reddit.com/r/PostgreSQL/comments/e0rx8l/i_was_missing_a_single_index_and_omgf_everything/ On Sun, Nov 24, 2019 at 5:20 PM Michael Paquier wrote: > > On Sun, Nov 24, 2019 at 09:31:58AM +0000, PG Doc comments form wrote: > > There needs to be a tutorial page explaining how to use pg_stat_all_tables > > to find missing indexes, or maybe just an example on monitoring-stats.html > > which is hopelessly inaccessible to a non-expert. I would have never been > > able to figure out anything close to the solution at > > https://www.reddit.com/r/PostgreSQL/comments/e0rx8l/i_was_missing_a_single_index_and_omgf_everything/ > > from the existing docs. > > Well, it may be as simple as that in some cases, but you also need to > consider other parameters in more complex cases, like: > - Actual CPU consumption done by backends. > - Get stats about predicates (WHERE and JOIN clauses). > - Physical disk access. > - Anything else I don't have on top of my mind. > > > Thank you for your kind consideration of this > > request; please do not hesitate to send instructions for how to submit a > > pull request for this, as I would gladly do so. Best regards, -Jim > > The Postgres mailing lists are old-school regarding that, so pull > requests sent to the git repository on github or such are not > accepted. Sending an email with a patch would be just but fine, and > here you would need to patch some of the *.sgml files in doc/. So if > you have anything you'd like to get changed with fresh ideas, let's > see how you would like things to change and then let's discuss about > it. > > Thanks, > -- > Michael