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.von...@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.
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?
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
