Re: idea: log_statement_sample_rate - bottom limit for sampling

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: idea: log_statement_sample_rate - bottom limit for sampling
Date: 2019-11-06 18:21:06
Message-ID: 20191106182106.dwdvxalewyydqbx3@development
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Sun, Aug 04, 2019 at 11:41:54PM +0200, Tomas Vondra wrote:
>On Sun, Aug 04, 2019 at 10:48:48PM +0200, Tomas Vondra wrote:
>>On Sun, Aug 04, 2019 at 04:25:12PM -0400, Tom Lane wrote:
>>>Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)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.
>FWIW I've reverted the log_statement_sample_rate (both from master and
>REL_12_STABLE). May the buildfarm be merciful to me.
>I've left the log_transaction_sample_rate in, as that seems unaffected
>by this discussion.

I've pushed the reworked version of log_statement_sample_rate patch [1].
If I understand correctly, that makes this patch unnecessary, and we
should mark it as rejected. Or do we still need it?


Tomas Vondra
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-11-06 18:34:02 Re: [Patch] optimizer - simplify $VAR1 IS NULL AND $VAR1 IS NOT NULL
Previous Message Pavel Stehule 2019-11-06 18:16:15 Re: dropdb --force