| From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
|---|---|
| To: | Adrien Nayrat <adrien(dot)nayrat(at)anayrat(dot)info>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, david(dot)rowley(at)2ndquadrant(dot)com, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: New GUC to sample log queries |
| Date: | 2018-11-19 13:46:30 |
| Message-ID: | 46944a05-55b3-c5c8-918a-89d65893856e@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dmitry Dolgov | 2018-11-19 13:52:05 | Re: New GUC to sample log queries |
| Previous Message | Tomas Vondra | 2018-11-19 13:40:03 | Re: New GUC to sample log queries |