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*.
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?
Nik
