Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dmJik-0006bd-Qe for pgsql-bugs@arkaria.postgresql.org; Mon, 28 Aug 2017 13:04:50 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dmJik-0005Yh-1m for pgsql-bugs@arkaria.postgresql.org; Mon, 28 Aug 2017 13:04:50 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dmJih-0005Y0-Uq; Mon, 28 Aug 2017 13:04:48 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dmJif-0007EH-Fd; Mon, 28 Aug 2017 13:04:46 +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 v7SD4evN005306; Mon, 28 Aug 2017 09:04:40 -0400 From: Tom Lane To: Amit Kapila cc: Robert Haas , Noah Misch , "Adam, Etienne (Nokia-TECH/Issy Les Moulineaux)" , PostgreSQL Bugs , "Duquesne, Pierre (Nokia-TECH/Issy Les Moulineaux)" , pgsql-hackers Subject: Re: [HACKERS] [postgresql 10 beta3] unrecognized node type: 90 In-reply-to: References: <11673.1502467154@sss.pgh.pa.us> <20170815025243.GA3986579@rfd.leadboat.com> <26053.1502804769@sss.pgh.pa.us> <2941.1502979564@sss.pgh.pa.us> <28782.1502992247@sss.pgh.pa.us> <29467.1502993219@sss.pgh.pa.us> <18650.1502995942@sss.pgh.pa.us> <1105.1503008416@sss.pgh.pa.us> <24667.1503865781@sss.pgh.pa.us> <3924.1503923486@sss.pgh.pa.us> Comments: In-reply-to Amit Kapila message dated "Mon, 28 Aug 2017 18:14:51 +0530" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5304.1503925480.1@sss.pgh.pa.us> Date: Mon, 28 Aug 2017 09:04:40 -0400 Message-ID: <5305.1503925480@sss.pgh.pa.us> List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-bugs Precedence: bulk Sender: pgsql-bugs-owner@postgresql.org Amit Kapila writes: > On Mon, Aug 28, 2017 at 6:01 PM, Tom Lane wrote: >> Um, what's different about that than before? > Earlier, we perform the rescan of all the nodes before ExecProcNode, > so workers will always start (restart) after the scan descriptor is > initialized. If what you're complaining about is that I put back the "if (outerPlan->chgParam == NULL)" test to allow postponement of the recursive ExecReScan call, I'm afraid that it's mere wishful thinking that omitting that test in nodeGather did anything. The nodes underneath the Gather are likely to do the same thing, so that the parallel table scan node itself is going to get a postponed rescan call anyway. See e.g. ExecReScanNestLoop(). I see your point that there's inadequate interlocking between resetting the parallel scan's shared state and starting a fresh set of workers, but that's a pre-existing bug. In practice I doubt it makes any difference, because according to my testing the leader will generally reach the table scan long before any workers do. It'd be nice to do better though. I'm inclined to think that what's needed is to move the reset of the shared state into a new "ExecParallelReInitializeDSM" plan tree walk, which would have to occur before we start the new set of workers. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs