Re: New GUC to sample log queries
Nikolay Samokhvalov <samokhvalov@gmail.com>
From: Nikolay Samokhvalov <samokhvalov@gmail.com>
To: alvherre@2ndquadrant.com
Cc: adrien.nayrat@anayrat.info, thomas.munro@enterprisedb.com, 9erthalion6@gmail.com, tomas.vondra@2ndquadrant.com, vik.fearing@2ndquadrant.com, robertmhaas@gmail.com, michael@paquier.xyz, David Rowley <david.rowley@2ndquadrant.com>, pgsql-hackers@postgresql.org
Date: 2018-11-30T06:42:42Z
Lists: pgsql-hackers
On Thu, Nov 29, 2018 at 1:49 PM Alvaro Herrera <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*. 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
Commits
-
Use pg_strong_random() to select each server process's random seed.
- 4203842a1cd0 12.0 landed
-
Use a separate random seed for SQL random()/setseed() functions.
- 6645ad6bdd81 12.0 landed
-
Marginal performance hacking in erand48.c.
- 6b9bba2df8d4 12.0 landed
-
Fix latent problem with pg_jrand48().
- e09046641114 12.0 landed
- f256995e33d2 10.7 landed
- d58e01f8abe2 11.2 landed
-
Silence compiler warning
- 9dc122585551 12.0 landed
-
Add log_statement_sample_rate parameter
- 88bdbd3f7460 12.0 landed