Re: backend type in log_line_prefix?
От | Justin Pryzby |
---|---|
Тема | Re: backend type in log_line_prefix? |
Дата | |
Msg-id | 20200310190142.GB29065@telsasoft.com обсуждение исходный текст |
Ответ на | Re: backend type in log_line_prefix? (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
Re: backend type in log_line_prefix?
|
Список | pgsql-hackers |
On Thu, Feb 13, 2020 at 06:43:32PM +0900, Fujii Masao wrote: > If we do this, backend type should be also included in csvlog? +1, I've been missing that Note, this patch seems to correspond to: b025f32e0b Add leader_pid to pg_stat_activity I had mentioned privately to Julien missing this info in CSV log. Should leader_pid be exposed instead (or in addition)? Or backend_type be a positive number giving the leader's PID if it's a parallel worker, or a some special negative number like -BackendType to indicate a nonparallel worker. NULL for a B_BACKEND which is not a parallel worker. My hope is to answer to questions like these: . is query (ever? usually?) using parallel paths? . is query usefully using parallel paths? . what queries are my max_parallel_workers(_per_process) being used for ? . Are certain longrunning or frequently running queries which are using parallel paths using all max_parallel_workers and precluding other queries from using parallel query ? Or, are semi-short queries sometimes precluding longrunning queries from using parallelism, when the long queries would better benefit ? I think this patch alone wouldn't provide that, and there'd need to either be a line logged for each worker. Maybe it'd log full query+details (ugh), or just log "parallel worker of pid...". Or maybe there'd be a new column with which the leader would log nworkers (workers planned vs workers launched - I would *not* want to get this out of autoexplain). -- Justin
В списке pgsql-hackers по дате отправления: