Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGbeG-0006wE-Kl for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Apr 2019 03:54:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hGbeE-0001QY-UM for pgsql-hackers@arkaria.postgresql.org; Wed, 17 Apr 2019 03:54:10 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGbeE-0001My-I2 for pgsql-hackers@lists.postgresql.org; Wed, 17 Apr 2019 03:54:10 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGbeC-000719-3D for pgsql-hackers@lists.postgresql.org; Wed, 17 Apr 2019 03:54:09 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x3H3s1Ns002019; Tue, 16 Apr 2019 23:54:02 -0400 From: Tom Lane To: Amit Langote cc: David Rowley , Yuzuko Hosoya , PostgreSQL Hackers Subject: Re: Runtime pruning problem In-reply-to: References: <001001d4f44b$2a2cca50$7e865ef0$@lab.ntt.co.jp> Comments: In-reply-to Amit Langote message dated "Wed, 17 Apr 2019 11:49:04 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2017.1555473241.1@sss.pgh.pa.us> Date: Tue, 16 Apr 2019 23:54:01 -0400 Message-ID: <2018.1555473241@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Amit Langote writes: > On 2019/04/17 11:29, David Rowley wrote: >> Where do you think the output list for EXPLAIN VERBOSE should put the >> output column list in this case? On the Append node, or just not show >> them? > Maybe, not show them? Yeah, I think that seems like a reasonable idea. If we show the tlist for Append in this case, when we never do otherwise, that will be confusing, and it could easily break plan-reading apps like depesz.com. What I'm more worried about is whether this breaks any internal behavior of explain.c, as the comment David quoted upthread seems to think. If we need to have a tlist to reference, can we make that code look to the pre-pruning plan tree, rather than the planstate tree? regards, tom lane