pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Justin Pryzby <pryzby@telsasoft.com>
To: Patrick Hemmer <postgresql@stormcloud9.net>
Cc: pgsql-performance@lists.postgresql.org, Adrien Nayrat <adrien.nayrat@anayrat.info>
Subject: Re: performance statistics monitoring without spamming logs
Date: Tue, 10 Jul 2018 13:38:28 -0500
Message-ID: <20180710183828.GB3890@telsasoft.com> (raw)
In-Reply-To: <7ffb9dbe-c76f-8ca3-12ee-7914ede872e6@stormcloud9.net>
References: <7ffb9dbe-c76f-8ca3-12ee-7914ede872e6@stormcloud9.net>

On Tue, Jul 10, 2018 at 01:54:12PM -0400, Patrick Hemmer wrote:
> I'm looking for a way of gathering performance stats in a more usable
> way than turning on `log_statement_stats` (or other related modules).
> The problem I have with the log_*_stats family of modules is that they
> log every single query, which makes them unusable in production. Aside
> from consuming space, there's also the problem that the log system
> wouldn't be able to keep up with the rate.
> 
> There are a couple ideas that pop into mind that would make these stats
> more usable:
> 1. Only log when the statement would otherwise already be logged. Such
> as due to the `log_statement` or `log_min_duration_statement` settings.

Did you see: (Added Adrien to Cc);
https://commitfest.postgresql.org/18/1691/

I don't think the existing patch does what you want, but perhaps all that's
needed is this:

        if (save_log_statement_stats)
+               if (log_sample_rate==1 || was_logged)
                ShowUsage("EXECUTE MESSAGE STATISTICS");

In any case, I'm thinking that your request could/should be considered by
whatever future patch implements sampling (if not implemented/included in the
patch itself).

If that doesn't do what's needed, that patch might still be a good crash course
in how to start implementing what you need (perhaps on top of that patch).

> 2. Make stats available in `pg_stat_statements` (or alternate view that
> could be joined on). The block stats are already available here, but
> others like CPU usage, page faults, and context switches are not.

pg_stat_statements is ./contrib/pg_stat_statements/pg_stat_statements.c which is 3k LOC.

getrusage stuff and log_*_stat stuff is in src/backend/tcop/postgres.c

Justin




view thread (8+ messages)  latest in thread

Message-ID: <20180710183828.GB3890@telsasoft.com>
Permalink:  ../20180710183828.GB3890@telsasoft.com/
Also on:    postgresql.org/message-id/20180710183828.GB3890@telsasoft.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: pryzby@telsasoft.com, postgresql@stormcloud9.net, adrien.nayrat@anayrat.info
  Subject: Re: performance statistics monitoring without spamming logs
  In-Reply-To: <20180710183828.GB3890@telsasoft.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox