Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jtwJI-000537-4M for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Jul 2020 16:55:40 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jtwJF-0000UP-AX for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Jul 2020 16:55:37 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jtwJF-0000UI-3D for pgsql-hackers@lists.postgresql.org; Fri, 10 Jul 2020 16:55:37 +0000 Received: from mail-il1-x144.google.com ([2607:f8b0:4864:20::144]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jtwJ7-0004gF-0m for pgsql-hackers@postgresql.org; Fri, 10 Jul 2020 16:55:36 +0000 Received: by mail-il1-x144.google.com with SMTP id h16so5610820ilj.11 for ; Fri, 10 Jul 2020 09:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=OKHh75p2QsQOVibNeSXTRxjie/cKD5aEr/M+OlIyblk=; b=S0e3ucpkjTIxbUkfP1do0muZAPfBFzozojgcDYUEZA4ZFnWnwrl+D0KvciivuPdsQu buJuEixU3semIvqcPxteII0wKR2Vz5kzVIzV0D4KUkPEdOQMAxMIY1CtT2Il8Fta0zoL FlUYMhIW7wJAogTIYbiHZ10vTv2XWxyb5++yksqEkmw+ll7xhXyiHdHEE/m/ifNoTbxb +5Dy/Q/ExTd6EvpKCOWvG0GrgszSuvSEN+QzB8+6uZTTNscxgNizHTb7TbtSc4LvPQlX zYMy/rK1xm4fwmd4NrUNcDGUxMr7WAV+SjrduGVgtBzZpR5OBz2DKien8g4jR5AXbP+A uamQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=OKHh75p2QsQOVibNeSXTRxjie/cKD5aEr/M+OlIyblk=; b=ekWZGyR8co0tk4a0uwWrcn4TmQZr+zHjn8G9eCNh7on+kdoBnZNO5Y0IE3Ts4iQCS7 djEAuUoNPUgmQyro/Eegrp3F8nEOSC8sqMd8b1ckLY0eik+NoVVrjDNUwUGQddxtJaR4 ugm6fOHj8mZ1kz9FVLDxEFbgkTFuevw9kvgCgkSWkLkrF1YaBvgQFhL/BAXGTHUvMdh7 nEdAWtEFX3Pq+kclhtQO054ny8s4RVQASP+OqAzbWPpR8d4wOoHQqUWvPfKtEBW9goMn 6mmfR78XBlUvCvInRy+UHoJIwsqy2WTQk2UptLsTMCwI8kEFXefXv7HCATfZ6xaH2pW6 m2zQ== X-Gm-Message-State: AOAM531EAxJ2c1sME6OSK0YMjQPdPcIHYIRKoWM7teh72hjRZoHY5z4o 94SOyeNAvIT8Nbd7tgUHDvy6vA== X-Google-Smtp-Source: ABdhPJyupr9ShNDYki/a8O+a2mO2h5nAmiKp3ISgi4uA7qx7QwF8psQnjY0ItKBLEWmQ/DsETVh+4w== X-Received: by 2002:a92:9144:: with SMTP id t65mr27729557ild.157.1594400126997; Fri, 10 Jul 2020 09:55:26 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id o19sm3971568iob.5.2020.07.10.09.55.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Jul 2020 09:55:26 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 25B778009C4; Fri, 10 Jul 2020 11:55:25 -0500 (CDT) Date: Fri, 10 Jul 2020 11:55:25 -0500 From: Justin Pryzby To: Alvaro Herrera Cc: Julien Rouhaud , pgsql-hackers@postgresql.org Subject: Re: expose parallel leader in CSV and log_line_prefix Message-ID: <20200710165524.GL26220@telsasoft.com> References: <20200318212511.GN26184@telsasoft.com> <20200710164529.GA23646@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200710164529.GA23646@alvherre.pgsql> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Fri, Jul 10, 2020 at 12:45:29PM -0400, Alvaro Herrera wrote: > On 2020-Mar-18, Justin Pryzby wrote: > > > On Sun, Mar 15, 2020 at 12:49:33PM +0100, Julien Rouhaud wrote: > > > template1=# SET log_temp_files=0; explain analyze SELECT a,COUNT(1) FROM t a JOIN t b USING(a) GROUP BY 1; > > 2020-03-15 21:20:47.288 CDT [5537 5537]LOG: statement: SET log_temp_files=0; > > SET > > 2020-03-15 21:20:47.289 CDT [5537 5537]LOG: statement: explain analyze SELECT a,COUNT(1) FROM t a JOIN t b USING(a) GROUP BY 1; > > 2020-03-15 21:20:51.253 CDT [5627 5537]LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp5627.0", size 6094848 > > 2020-03-15 21:20:51.253 CDT [5627 5537]STATEMENT: explain analyze SELECT a,COUNT(1) FROM t a JOIN t b USING(a) GROUP BY 1; > > 2020-03-15 21:20:51.254 CDT [5626 5537]LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp5626.0", size 6103040 > > 2020-03-15 21:20:51.254 CDT [5626 5537]STATEMENT: explain analyze SELECT a,COUNT(1) FROM t a JOIN t b USING(a) GROUP BY 1; > > 2020-03-15 21:20:51.263 CDT [5537 5537]LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp5537.1.sharedfileset/o15of16.p0.0", size 557056 > > I think it's overly verbose; all non-parallel backends are going to get > their own PID twice, and I'm not sure this is going to be great to > parse. I think it would be more sensible that if the process does not > have a parent (leader), %P expands to empty. That's what's done. + Process ID of the parallel group leader if this process was + at some point involved in parallel query, otherwise null. For a + parallel group leader itself, this field is set to its own process + ID. 2020-07-10 11:53:32.304 CDT [16699 ]LOG: statement: SELECT 1; 2020-07-10 11:53:32.304 CDT,"pryzbyj","postgres",16699,"[local]",5f089d0b.413b,1,"idle",2020-07-10 11:53:31 CDT,3/4,0,LOG,00000,"statement: SELECT 1;",,,,,,,,,"psql","client backend", -- Justin