Re: idea: log_statement_sample_rate - bottom limit for sampling - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: idea: log_statement_sample_rate - bottom limit for sampling
Date
Msg-id 20190804204848.7f7ypsbijpgxojxx@development
Whole thread Raw
In response to Re: idea: log_statement_sample_rate - bottom limit for sampling  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: idea: log_statement_sample_rate - bottom limit for sampling
List pgsql-hackers
On Sun, Aug 04, 2019 at 04:25:12PM -0400, Tom Lane wrote:
>Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
>> On Sun, Aug 04, 2019 at 03:16:12PM -0400, Tom Lane wrote:
>>> Isn't the issue here the interaction between log_transaction_sample_rate
>>> and log_min_duration_statement?
>
>> No, that interaction only affects statement-level sampling.
>
>OK, I was confusing the features.
>
>> For transaction-level sampling we do the sampling independently of the
>> statement duration, i.e. we when starting a transaction we determine
>> whether the whole transaction will be sampled. It has nothing to do with
>> the proposed log_statement_sample_limit.
>
>So, to clarify: our plan is that a given statement will be logged
>if any of these various partial-logging features says to do so?
>

Yes, I think that's the expected behavior.

- did it exceed log_min_duration_statement? -> log it
- is it part of sampled xact? -> log it
- maybe sample the statement (to be reverted / reimplemented)

>(And the knock on HEAD's behavior is exactly that it breaks that
>independence for log_min_duration_statement.)
>

Yeah. There's no way to use sampling, while ensure logging of all
queries longer than some limit.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services 



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: idea: log_statement_sample_rate - bottom limit for sampling
Next
From: Alexander Lakhin
Date:
Subject: Fix typos and inconsistencies for HEAD (take 9)