From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
cc: Pavel Stehule <pavel.stehule@gmail.com>,
        Adrien Nayrat <adrien.nayrat@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: idea: log_statement_sample_rate - bottom limit for sampling
In-reply-to: <20190727221948.irg6sfqh57dynoc7@development>
References: 
 <CAFj8pRDS8tQ3Wviw9=AvODyUciPSrGeMhJi_WPE+EB8+4gLL-Q@mail.gmail.com>
 <156292912396.1365.3073279552263868317.pgcf@coridan.postgresql.org>
 <156292957348.1365.8079060287740507529.pgcf@coridan.postgresql.org>
 <CAFj8pRB=bHQ=H3wbX1Qs9ViM-JeywvFm_k-ey1cOmSbWe=O0ew@mail.gmail.com>
 <20190727221948.irg6sfqh57dynoc7@development>
Comments: In-reply-to Tomas Vondra <tomas.vondra@2ndquadrant.com>
	message dated "Sun, 28 Jul 2019 00:19:48 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <32569.1564515838.1@sss.pgh.pa.us>
Date: Tue, 30 Jul 2019 15:43:58 -0400
Message-ID: <32570.1564515838@sss.pgh.pa.us>
Precedence: bulk

Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> I've started reviewing this patch, thinking that maybe I could get it
> committed as it's marked as RFC. In general I agree with having this
> fuature, but I think we need to rethink the GUC because the current
> approach is just confusing.
> ...
> What I think we should do instead is to use two minimum thresholds.
> 1) log_min_duration_sample - enables sampling of commands, using the
> existing GUC log_statement_sample_rate
> 2) log_min_duration_statement - logs all commands exceeding this
> I think this is going to be much easier for users to understand.

I agree with Tomas' idea.

> The one difference between those approaches is in how they work with
> existing current settings. That is, let's say you have
>   log_min_duration_statement = 1000
>   log_statement_sample_rate = 0.01
> then no queries below 1000ms will be logged, and 1% of longer queries
> will be sampled. And with the original config (as proposed in v3 of the
> patch), this would still work the same way.
> With the new approach (two min thresholds) it'd behave differently,
> because we'd log *all* queries longer than 1000ms (not just 1%). And
> whether we'd sample any queries (using log_statement_sample_rate) would
> depend on how we'd pick the default value for the other threshold.

Well, we do not need to have a backwards-compatibility problem
here, because we have yet to release a version containing
log_statement_sample_rate.  I do not think it's too late to decide
that v12's semantics for that are broken, and either revert that
patch in v12, or back-patch a fix to make it match this idea.

			regards, tom lane