Horton

Re: New GUC to sample log queries

Tomas Vondra <tomas.vondra@2ndquadrant.com>

View thread View on postgr.es
From: Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Adrien Nayrat <adrien.nayrat@anayrat.info>, Dmitry Dolgov <9erthalion6@gmail.com>, Vik Fearing <vik.fearing@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael@paquier.xyz>, david.rowley@2ndquadrant.com, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2018-11-19T13:46:30Z
Lists: pgsql-hackers 

On 11/18/18 10:52 AM, Adrien Nayrat wrote:
> ...
> Alors, I wonder if we should use the same logic for other parameters, such as
> log_statement_stats
> log_parser_stats
> log_planner_stats
> log_executor_stats
> 
 > It was mentioned in this thread
 > 
https://www.postgresql.org/message-id/20180710183828.GB3890%40telsasoft.com


You mean apply sampling to those logging options too? I doubt that would 
be very useful, as the those options are IMHO meant for development. 
Maybe tracking some of the info would be useful, but integrating it into 
pg_stat_statements seems like a better solution than just dumping it 
into the server log.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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