From: Antonin Houska <ah@cybertec.at>
To: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
cc: Tom Lane <tgl@sss.pgh.pa.us>,
    Andrew Gierth <andrew@tao11.riddles.org.uk>,
    pgsql-hackers@postgresql.org
Subject: Re: Problems with plan estimates in postgres_fdw
In-reply-to: <5C6A5FD3.8080102@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> <19433.1549962210@localhost>
 <5C669DFD.30002@lab.ntt.co.jp> <16616.1550234762@localhost>
 <5C6A5FD3.8080102@lab.ntt.co.jp>
Comments: In-reply-to Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
   message dated "Mon, 18 Feb 2019 16:33:39 +0900."
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Mon, 18 Feb 2019 15:21:11 +0100
Message-ID: <30524.1550499671@localhost>
Precedence: bulk

Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp> wrote:

> (2019/02/15 21:46), Antonin Houska wrote:
> > ok, I understand now. I assume that the patch
> >
> > https://www.postgresql.org/message-id/5C66A056.60007%40lab.ntt.co.jp
> >
> > obsoletes the code snippet we discussed above.
>=20
> Sorry, I don't understand this.  Could you elaborate on that?

I thought that the assignments

+ 			startup_cost +=3D outerrel->reltarget->cost.startup;

and

+ 			run_cost +=3D outerrel->reltarget->cost.per_tuple * input_rows;

in the patch you posted in
https://www.postgresql.org/message-id/5C66A056.60007%40lab.ntt.co.jp do
replace

+			startup_cost +=3D foreignrel->reltarget->cost.startup;

and

+			run_cost +=3D foreignrel->reltarget->cost.per_tuple * rows;

respectively, which you originally included in the following part of
0001-postgres_fdw-Perform-UPPERREL_ORDERED-step-remotely-v3.patch:

@@ -2829,6 +2872,22 @@ estimate_path_cost_size(PlannerInfo *root,
 			run_cost +=3D foreignrel->reltarget->cost.per_tuple * rows;
 		}
=20
+		/*
+		 * If this is an UPPERREL_ORDERED step on the final scan/join
+		 * relation, the costs obtained from the cache wouldn't yet contain
+		 * the eval cost for the final scan/join target, which would have been
+		 * updated by apply_scanjoin_target_to_paths(); add the eval cost now.
+		 */
+		if (fpextra && !IS_UPPER_REL(foreignrel))
+		{
+			/* The costs should have been obtained from the cache. */
+			Assert(fpinfo->rel_startup_cost >=3D 0 &&
+				   fpinfo->rel_total_cost >=3D 0);
+
+			startup_cost +=3D foreignrel->reltarget->cost.startup;
+			run_cost +=3D foreignrel->reltarget->cost.per_tuple * rows;
+		}
+
 		/*
 		 * Without remote estimates, we have no real way to estimate the cost
 		 * of generating sorted output.  It could be free if the query plan


--=20
Antonin Houska
Cybertec Sch=C3=B6nig & Sch=C3=B6nig GmbH
Gr=C3=B6hrm=C3=BChlgasse 26, A-2700 Wiener Neustadt
Web: https://www.cybertec-postgresql.com