On 11/30/18 7:42 AM, Nikolay Samokhvalov wrote:
On Thu, Nov 29, 2018 at 1:49 PM Alvaro Herrera <alvhe...@2ndquadrant.com
<mailto:alvhe...@2ndquadrant.com>> wrote:
Thanks! I pushed this with two changes -- one was to reword the docs a
bit more, and the other was to compute in_sample only if it's going to
be used (when exceeded is true). I hope this won't upset any
compilers ...
This is a great news – I can imaging how helpful this feature will be
for query analysis and
troubleshooting.
At the same time, there is an approach, when we use application (client)
code or pgbouncer's
connect_query parameter to perform sampled logging (with
log_min_duration_statement = 0)
of n% of all *sessions* or *transactions*.
Good idead! Unfortunately it require pgbouncer, but I keep this trick in
mind.
If you use single-query transactions only, new parameter will do
equivalent job for you, while
significantly simplifying you life (pgbouncer is not required and you
don't need to patch application
code). However, if you have multi-statement transaction,
log_statement_sample_rate will not
be enough for troubleshooting – logging just a single statement of a
multi-statement transaction
won't really help to troubleshoot in many cases.
That being said, I wonder, does it make sense to think about extending
the functionality
just committed, with some options to to log all statements of n% of
transactions (or sessions)?
In other words, allowing to choose, at which level perform sampling –
statement, transaction, or
session?
+1, I like this idea.
