Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dhcBW-0004Re-25 for pgsql-bugs@arkaria.postgresql.org; Tue, 15 Aug 2017 13:47:06 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dhcBU-0002ed-LF for pgsql-bugs@arkaria.postgresql.org; Tue, 15 Aug 2017 13:47:04 +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 1dhcAk-0007GS-Vj; Tue, 15 Aug 2017 13:46:19 +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 1dhcAi-0002gP-Gs; Tue, 15 Aug 2017 13:46:17 +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 v7FDk9Ab026054; Tue, 15 Aug 2017 09:46:09 -0400 From: Tom Lane To: Robert Haas cc: Amit Kapila , 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> Comments: In-reply-to Robert Haas message dated "Tue, 15 Aug 2017 09:20:41 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26052.1502804769.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Aug 2017 09:46:09 -0400 Message-ID: <26053.1502804769@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 Robert Haas writes: > On Tue, Aug 15, 2017 at 7:31 AM, Amit Kapila wr= ote: >> Attached patch fixes the issue for me. I have locally verified that >> the gather merge gets executed in rescan path. I haven't added a test >> case for the same as having gather or gather merge on the inner side >> of join can be time-consuming. However, if you or others feel that it >> is important to have a test to cover this code path, then I can try to >> produce one. > Committed. > I believe that between this commit and the test-coverage commit from > Andres, this open item is reasonably well addressed. If someone > thinks more needs to be done, please specify. Thanks. How big a deal do we think test coverage is? It looks like ExecReScanGatherMerge is identical logic to ExecReScanGather, which *is* covered according to coverage.postgresql.org, but it wouldn't be too surprising if they diverge in future. I should think it wouldn't be that expensive to create a test case, if you already have test cases that invoke GatherMerge. Adding a right join against a VALUES clause with a small number of entries, and a non-mergeable/hashable join clause, ought to do it. regards, tom lane --=20 Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs