Re: New GUC to sample log queries

Adrien NAYRAT <adrien.nayrat@anayrat.info>

From: Adrien Nayrat <adrien.nayrat@anayrat.info>
To: Vik Fearing <vik.fearing@2ndquadrant.com>, Michael Paquier <michael@paquier.xyz>
Cc: David Rowley <david.rowley@2ndquadrant.com>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Date: 2018-07-10T18:34:15Z
Lists: pgsql-hackers

Attachments

On 06/27/2018 11:13 PM, Adrien Nayrat wrote:
>> 3) Is it intentional to only sample with log_min_duration_statement and
>> not also with log_duration?  It seems like it should affect both.  In
>> both cases, the name is too generic.  Something called "log_sample_rate"
>> should sample **everything**.
> I do not think it could be useful to sample other case such as log_duration.
> 
> But yes, the GUC is confusing and I am not comfortable to introduce a new GUC in
> my initial patch.
> 
> Maybe we should adapt current GUC with something like :
> 
> log_min_duration_statement = <time>,<sample rate>>
> This give :
> 
> log_min_duration_statement = 0,0.1
> 
> Equivalent to :
> log_min_duration_statement = 0
> log_sample_rate = 0.1
> 
> Thought?
> 

After reflection it seems a bad idea :

  * it breaks compatibility with external tools
  * it introduce a kind of "composite" GUC which may add complexity to use. For
example in pg_settings view.

What do you think of : log_min_duration_statement_sample ? Is it too long?


I saw a few days ago this error on http://commitfest.cputube.org

postgres.sgml:5202: element xref: validity error : IDREF attribute linkend
references an unknown ID "log_min_duration_statement"

Patch attached with fix on linkend marker

Regards,

-- 
Adrien

Commits

  1. Use pg_strong_random() to select each server process's random seed.

  2. Use a separate random seed for SQL random()/setseed() functions.

  3. Marginal performance hacking in erand48.c.

  4. Fix latent problem with pg_jrand48().

  5. Silence compiler warning

  6. Add log_statement_sample_rate parameter