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 1jWo2A-0000LI-8W for pgsql-general@arkaria.postgresql.org; Thu, 07 May 2020 21:26:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jWo29-0006PE-5U for pgsql-general@arkaria.postgresql.org; Thu, 07 May 2020 21:26:21 +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 1jWo28-0006P3-UA; Thu, 07 May 2020 21:26:20 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jWo22-0005hR-FJ; Thu, 07 May 2020 21:26:20 +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 047LQ85T032489; Thu, 7 May 2020 17:26:08 -0400 From: Tom Lane To: "David G. Johnston" cc: Amarendra Konda , Adrian Klaver , pgsql-performance@lists.postgresql.org, pgsql-general Subject: Re: Explain plan changes - IN CLAUSE ( Passing direct values Vs INNER Query ) In-reply-to: References: <92fe033c-0221-30e3-1143-de8b0c8d923b@aklaver.com> Comments: In-reply-to "David G. Johnston" message dated "Thu, 07 May 2020 14:21:05 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <32487.1588886768.1@sss.pgh.pa.us> Date: Thu, 07 May 2020 17:26:08 -0400 Message-ID: <32488.1588886768@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk "David G. Johnston" writes: > On Thu, May 7, 2020 at 10:49 AM Amarendra Konda > wrote: >> Can you please explain, why it is getting more columns in output, even >> though we have asked for only one column ? >> * Output: pa.process_activity_id, pa.process_activity_type, pa.voice_url, >> pa.process_activity_user_id, pa.app_id, pa.process_instance_id, pa.alias, >> pa.read_by_user, pa.source, pa.label_category_id, pa.label_id, >> pa.csat_response_id, m.process_activity_fragments, pa.created, pa.updated, >> pa.rule_id, pa.marketing_reply_id, pa.delivered_at, pa.reply_fragments, >> pa.status_fragment, pa.internal_meta, pa.interaction_id, >> pa.do_not_translate, pa.should_translate, pa.in_reply_to* > Not knowing the source code in this area at all... > I'm pretty sure its because it doesn't matter. It's actually intentional, to save a projection step within that plan node. We'll discard the extra columns once it matters, at some higher plan level. (There have been some debates on -hackers about whether this optimization is still worth anything, given all the executor improvements that have been made since it went in. But it was clearly a win at the time.) regards, tom lane