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 1gfWvC-0008Vp-Rm for pgsql-hackers@arkaria.postgresql.org; Fri, 04 Jan 2019 21:22:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gfWvA-0006rR-Pi for pgsql-hackers@arkaria.postgresql.org; Fri, 04 Jan 2019 21:22:24 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gfWvA-0006qV-HD for pgsql-hackers@lists.postgresql.org; Fri, 04 Jan 2019 21:22:24 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gfWv8-0007rN-4q for pgsql-hackers@lists.postgresql.org; Fri, 04 Jan 2019 21:22:24 +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 x04LMHrF025354; Fri, 4 Jan 2019 16:22:17 -0500 From: Tom Lane To: David Rowley cc: Mark Dilger , PostgreSQL Hackers Subject: Re: "SELECT ... FROM DUAL" is not quite as silly as it appears In-reply-to: <20472.1546631337@sss.pgh.pa.us> References: <15944.1521127664@sss.pgh.pa.us> <9565.1539573909@sss.pgh.pa.us> <154342395130.2093.8013327151440360209.pgcf@coridan.postgresql.org> <12357.1543518669@sss.pgh.pa.us> <20472.1546631337@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Fri, 04 Jan 2019 14:48:57 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <25352.1546636937.1@sss.pgh.pa.us> Date: Fri, 04 Jan 2019 16:22:17 -0500 Message-ID: <25353.1546636937@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I wrote: > If you reverse out just that change you'll see why I added it: without it, > the plan for the earlier "test a corner case in which we shouldn't apply > the star-schema optimization" isn't optimized as much as I thought it > should be. Hmm ... looking at this closer, it seems like this patch probably breaks what that regression test case was actually meant to test, ie once we've deleted the VALUES subselects from the jointree, it's likely that the planner join-ordering mistake that was testing for can no longer happen, because the join just plain doesn't exist. I'll plan to deal with that by running the test case with actual small tables instead of VALUES subselects. It might be useful to run the test case in its current form as an exercise for the RTE_RESULT optimizations, but that would be separate from its current intention. regards, tom lane