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 1polTD-0002nI-UN for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Apr 2023 13:34:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1polTA-0005Wb-Um for pgsql-hackers@arkaria.postgresql.org; Tue, 18 Apr 2023 13:34:04 +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 1polTA-0005WQ-LQ for pgsql-hackers@lists.postgresql.org; Tue, 18 Apr 2023 13:34:04 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1polT7-003djs-Ma for pgsql-hackers@lists.postgresql.org; Tue, 18 Apr 2023 13:34:03 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 33IDXv2K2636189; Tue, 18 Apr 2023 09:33:57 -0400 From: Tom Lane To: Richard Guo cc: pgsql-hackers@lists.postgresql.org Subject: Re: Allowing parallel-safe initplans In-reply-to: References: <1129530.1681317832@sss.pgh.pa.us> <1315906.1681394451@sss.pgh.pa.us> <2425967.1681743873@sss.pgh.pa.us> Comments: In-reply-to Richard Guo message dated "Tue, 18 Apr 2023 15:14:01 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <2636187.1681824837.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Tue, 18 Apr 2023 09:33:57 -0400 Message-ID: <2636188.1681824837@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Richard Guo writes: > On Mon, Apr 17, 2023 at 11:04 PM Tom Lane wrote: >> I wondered about that too, but how come neither of us saw non-cosmetic >> failures (ie, actual query output changes not just EXPLAIN changes) >> when we tried this? > Sorry I forgot to mention that I did see query output changes after > moving the initPlans to the Gather node. Hmm, my memory was just of seeing the EXPLAIN output changes, but maybe those got my attention to the extent of missing the others. > It seems that in this case the top_plan does not have any extParam, so > the Gather node that is added atop the top_plan does not have a chance > to get its initParam filled in set_param_references(). Oh, so maybe we'd need to copy up extParam as well? But it's largely moot, since I don't see a good way to avoid breaking the EXPLAIN output. regards, tom lane