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 1gSL7b-0006ED-I8 for pgsql-hackers@arkaria.postgresql.org; Thu, 29 Nov 2018 12:08:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gSL7Z-0000bT-Jy for pgsql-hackers@arkaria.postgresql.org; Thu, 29 Nov 2018 12:08:41 +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 1gSL7Z-0000bK-7E for pgsql-hackers@lists.postgresql.org; Thu, 29 Nov 2018 12:08:41 +0000 Received: from mail.postgrespro.ru ([93.174.131.138]) by magus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gSL7R-0003ZU-Uo for pgsql-hackers@lists.postgresql.org; Thu, 29 Nov 2018 12:08:40 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.postgrespro.ru (Postfix) with ESMTP id 8366621CEB05; Thu, 29 Nov 2018 15:08:32 +0300 (MSK) X-Virus-Scanned: Debian amavisd-new at postgrespro.ru X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-99 required=4 WHITELISTED tests=[] autolearn=unavailable Received: from [192.168.27.182] (gw.postgrespro.ru [93.174.131.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id 3E8E021CC35E; Thu, 29 Nov 2018 15:08:31 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1543493312; bh=tDVePT+3Z/vXpiQ7rt2niST6YeEyDKhKt69JDhwYb5Y=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=SxNn9nxQfPoAmVFAGD5frp92aRmnd7C2U1yhEz1VZvv5thxO3GF2I3erOJpMvLLRI uNLYJZuNSrxReZriECaqNLlH3SAwvPl98j2PEcRyD+IgMnNoV4UTKy4tCfGDbrRT97 /UcvtDglsHKzpURpBZt0QAoMpmCmrUPyDCp9pPjk= Subject: Re: "SELECT ... FROM DUAL" is not quite as silly as it appears To: pgsql-hackers@lists.postgresql.org, Tom Lane Cc: Mark Dilger References: <15944.1521127664@sss.pgh.pa.us> <154342395130.2093.8013327151440360209.pgcf@coridan.postgresql.org> <154342412161.2094.14859341952034622342.pgcf@coridan.postgresql.org> From: Alexander Kuzmenkov Message-ID: <6d51c9bb-ccc6-92fd-b6ac-05f0d5546d70@postgrespro.ru> Date: Thu, 29 Nov 2018 15:08:31 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <154342412161.2094.14859341952034622342.pgcf@coridan.postgresql.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I was also looking at this patch, here are some things I noticed: In remove_useless_results_recurse where it processes JOIN_SEMI there is this comment:                  * However, we can't simplify if there are PHVs to evaluate at                  * the RTE_RESULT ... but that's impossible isn't it? Is that impossible because the RHS of semi join can't be used above it? Let's write this down. There is similar code above for JOIN_LEFT and it does have to check for PHVs, so a comment that clarifies the reasons for the difference would help. Also around there:                 if ((varno = is_result_ref(root, j->rarg)) != 0 && I'd expect a function that starts with "is_" to return a bool, so this catches the eye. Maybe varno = get_result_relid()? Looking at the coverage report of regression tests, most of the new code is covered except for the aforementioned simplification of JOIN_LEFT and JOIN_RIGHT, but it's probably not worth adding a special test. I checked these cases manually and they work OK. I also repeated the benchmark with trivial select and can confirm that there is no change in performance. -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company