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 1gtQ6k-0000gF-6X for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Feb 2019 04:55:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gtQ6h-00032E-LI for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Feb 2019 04:55:43 +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 1gtQ6h-00031s-Dq for pgsql-hackers@lists.postgresql.org; Tue, 12 Feb 2019 04:55:43 +0000 Received: from tama500.ecl.ntt.co.jp ([129.60.39.148]) by magus.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gtQ6Y-0000VJ-JK for pgsql-hackers@postgresql.org; Tue, 12 Feb 2019 04:55:42 +0000 Received: from vc2.ecl.ntt.co.jp (vc2.ecl.ntt.co.jp [129.60.86.154]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id x1C4tDcO014159; Tue, 12 Feb 2019 13:55:13 +0900 Received: from vc2.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id A1745638A89; Tue, 12 Feb 2019 13:55:13 +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 959786383E2; Tue, 12 Feb 2019 13:55:13 +0900 (JST) Received: from [IPv6:::1] (unknown [129.60.241.75]) by jcms-pop21.ecl.ntt.co.jp (Postfix) with ESMTPSA id 8E0EC4008AD; Tue, 12 Feb 2019 13:55:13 +0900 (JST) Message-ID: <5C6251A7.40204@lab.ntt.co.jp> Date: Tue, 12 Feb 2019 13:55:03 +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: Problems with plan estimates in postgres_fdw References: <87pnz1aby9.fsf@news-spur.riddles.org.uk> <1175.1533220908@sss.pgh.pa.us> <5BB739CD.6040002@lab.ntt.co.jp> <5BBC4140.50403@lab.ntt.co.jp> <5C17A00E.5000005@lab.ntt.co.jp> <5C232F39.9060509@lab.ntt.co.jp> <5C25C7B5.2010802@lab.ntt.co.jp> <5C518631.5080401@lab.ntt.co.jp> <10994.1549559088@localhost> <5C5D778F.3080501@lab.ntt.co.jp> In-Reply-To: <5C5D778F.3080501@lab.ntt.co.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CC-Mail-RelayStamp: 1 To: Antonin Houska Cc: Tom Lane , Andrew Gierth , pgsql-hackers@postgresql.org X-TM-AS-MML: disable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk (2019/02/08 21:35), Etsuro Fujita wrote: > (2019/02/08 2:04), Antonin Houska wrote: >> * add_foreign_ordered_paths() >> >> Exprssion root->upper_targets[UPPERREL_FINAL] is used to access the >> target. >> >> I think create_ordered_paths() should actually set the target so that >> postgresGetForeignUpperPaths() can simply find it in >> output_rel->reltarget. This is how postgres_fdw already retrieves the >> target >> for grouped paths. Small patch is attached that makes this possible. > > Seems like a good idea. Thanks for the patch! Will review. Here are my review comments: root->upper_targets[UPPERREL_FINAL] = final_target; + root->upper_targets[UPPERREL_ORDERED] = final_target; root->upper_targets[UPPERREL_WINDOW] = sort_input_target; root->upper_targets[UPPERREL_GROUP_AGG] = grouping_target; I think that's a good idea. I think we'll soon need the PathTarget for UPPERREL_DISTINCT, so how about saving that as well like this? root->upper_targets[UPPERREL_FINAL] = final_target; + root->upper_targets[UPPERREL_ORDERED] = final_target; + root->upper_targets[UPPERREL_DISTINCT] = sort_input_target; root->upper_targets[UPPERREL_WINDOW] = sort_input_target; root->upper_targets[UPPERREL_GROUP_AGG] = grouping_target; Another is about this: /* + * Set reltarget so that it's consistent with the paths. Also it's more + * convenient for FDW to find the target here. + */ + ordered_rel->reltarget = target; I think this is correct if there are no SRFs in the targetlist, but otherwise I'm not sure this is really correct because the relation's reltarget would not match the target of paths added to the relation after adjust_paths_for_srfs(). Having said that, my question here is: do we really need this (and the same for UPPERREL_FINAL you added)? For the purpose of the FDW convenience, the upper_targets[] change seems to me to be enough. Best regards, Etsuro Fujita