Re: backend type in log_line_prefix?

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: backend type in log_line_prefix?
Date: 2020-03-10 19:01:43
Message-ID: 20200310190142.GB29065@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Laurenz Albe 2020-03-10 19:07:03 Re: Berserk Autovacuum (let's save next Mandrill)
Previous Message Tom Lane 2020-03-10 18:55:20 Re: Constraint's NO INHERIT option is ignored in CREATE TABLE LIKE statement