Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fcUSc-0000Hb-Kq for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Jul 2018 11:36:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fcUSZ-0007z3-KN for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Jul 2018 11:36:03 +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.89) (envelope-from ) id 1fcUSZ-0007yw-AJ for pgsql-hackers@lists.postgresql.org; Mon, 09 Jul 2018 11:36:03 +0000 Received: from tama50.ecl.ntt.co.jp ([129.60.39.147]) by makus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fcUSR-0003mi-Hm for pgsql-hackers@postgresql.org; Mon, 09 Jul 2018 11:36:01 +0000 Received: from vc2.ecl.ntt.co.jp (vc2.ecl.ntt.co.jp [129.60.86.154]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id w69BZreT018294; Mon, 9 Jul 2018 20:35:53 +0900 Received: from vc2.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 2D73B638C0B; Mon, 9 Jul 2018 20:35:53 +0900 (JST) Received: from jcms-pop21.ecl.ntt.co.jp (jcms-pop21.ecl.ntt.co.jp [129.60.87.134]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 21DFC638BB4; Mon, 9 Jul 2018 20:35:53 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.241.75]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id 19F47400967; Mon, 9 Jul 2018 20:35:53 +0900 (JST) Message-ID: <5B434886.9010107@lab.ntt.co.jp> Date: Mon, 09 Jul 2018 20:35:34 +0900 From: Etsuro Fujita User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 Subject: Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled. References: <5AFC0865.8050802@lab.ntt.co.jp> <5AFD6580.5090308@lab.ntt.co.jp> <5AFE81CC.8000508@lab.ntt.co.jp> <5B17C5EC.1090602@lab.ntt.co.jp> <5B1E5071.1000704@lab.ntt.co.jp> <5B23A964.9020800@lab.ntt.co.jp> <5B28FB19.3090809@lab.ntt.co.jp> <5B362B38.2000103@lab.ntt.co.jp> <5B3CB833.4040005@lab.ntt.co.jp> <5B3F4BAA.3050601@lab.ntt.co.jp> <5B4340E9.3030707@lab.ntt.co.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: 1 To: Ashutosh Bapat Cc: Rajkumar Raghuwanshi , pgsql-hackers X-TM-AS-MML: disable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk (2018/07/09 20:06), Ashutosh Bapat wrote: > On Mon, Jul 9, 2018 at 4:33 PM, Etsuro Fujita > wrote: >>> As I said, we do spend cycles in that function testing whether a node >>> is Aggref or not even when the query doesn't have aggregates or >>> grouping OR spend cycles in testing whether a node is a PlaceHolderVar >>> when the query doesn't produce any. So, I don't see any problem with >>> spending a few cycles testing whether a node is ConvertRowtypeExpr or >>> not when a ConvertRowtypeExpr is not in the query or command. That's >>> not a huge performance trouble. I would be happy to change my mind, if >>> you show me performance different with and without this patch in >>> planning. I haven't seen any. >> >> >> I have to admit that the case in [1] wouldn't affect the performance, but my >> concern is that there might be some cases where the test affects >> performance. > > What are those cases? Can you please provide any numbers supporting your claim? I don't have any numbers right now, so that is nothing but a concern. But as I said in a previous email, in the approach I proposed, we don't need to spend extra cycles where partitioning is not involved. I think that is a good thing in itself. No? Best regards, Etsuro Fujita