On 11/30/18 7:42 AM, Nikolay Samokhvalov wrote:
> On Thu, Nov 29, 2018 at 1:49 PM Alvaro Herrera <alvherre@2ndquadrant.com
> <mailto:alvherre@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.