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 1h2II0-00070S-FQ for pgsql-hackers@arkaria.postgresql.org; Fri, 08 Mar 2019 16:24:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1h2IHy-0003Qz-N7 for pgsql-hackers@arkaria.postgresql.org; Fri, 08 Mar 2019 16:24:02 +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 1h2IHx-0003Qs-QE for pgsql-hackers@lists.postgresql.org; Fri, 08 Mar 2019 16:24:01 +0000 Received: from mx1.mailbox.org ([80.241.60.212]) by magus.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h2IHt-0004Lg-SK for pgsql-hackers@postgresql.org; Fri, 08 Mar 2019 16:24:01 +0000 Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:105:465:1:2:0]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mx1.mailbox.org (Postfix) with ESMTPS id 758384BDEF; Fri, 8 Mar 2019 17:23:55 +0100 (CET) X-Virus-Scanned: amavisd-new at heinlein-support.de Received: from smtp2.mailbox.org ([80.241.60.241]) by spamfilter04.heinlein-hosting.de (spamfilter04.heinlein-hosting.de [80.241.56.122]) (amavisd-new, port 10030) with ESMTP id hCiAbbrn1sRc; Fri, 8 Mar 2019 17:23:48 +0100 (CET) From: Antonin Houska To: Etsuro Fujita cc: Tom Lane , Andrew Gierth , pgsql-hackers@postgresql.org Subject: Re: Problems with plan estimates in postgres_fdw In-reply-to: <5C7E4127.2030802@lab.ntt.co.jp> 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> <5C6D474F.5010703@lab.ntt.co.jp> <30939.1550848901@localhost> <5C73B7FB.2010309@lab.ntt.co.jp> <7520.1551439018@localhost> <5C7E4127.2030802@lab.ntt.co.jp> Comments: In-reply-to Etsuro Fujita message dated "Tue, 05 Mar 2019 18:28:07 +0900." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <8641.1552062349.1@localhost> Content-Transfer-Encoding: quoted-printable Date: Fri, 08 Mar 2019 17:25:49 +0100 Message-ID: <8642.1552062349@localhost> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Etsuro Fujita wrote: > (2019/03/01 20:16), Antonin Houska wrote: > > Etsuro Fujita wrote: > = > >> Conversely, it appears that add_foreign_ordered_paths() added by the = patchset > >> would generate such pre-sorted paths *redundantly* when the input_rel= is the > >> final scan/join relation. Will look into that. > > > > Currently I have no idea how to check the plan created by FDW at the > > UPPERREL_ORDERED stage, except for removing the sort from the > > UPPERREL_GROUP_AGG stage as I proposed here: > > > > https://www.postgresql.org/message-id/11807.1549564431%40localhost > = > I don't understand your words "how to check the plan created by FDW". Co= uld > you elaborate on that a bit more? I meant that I don't know how to verify that the plan that sends the ORDER= BY clause to the remote server was created at the UPPERREL_ORDERED and not at UPPERREL_GROUP_AGG. However if the ORDER BY clause really should not be ad= ded at the UPPERREL_GROUP_AGG stage and if we ensure that it no longer happens= , then mere presence of ORDER BY in the (remote) plan means that the UPPERREL_ORDERED stage works fine. -- = Antonin Houska https://www.cybertec-postgresql.com