Etsuro Fujita <fujita.ets...@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. > > Sorry, I don't understand this. Could you elaborate on that?
I thought that the assignments + startup_cost += outerrel->reltarget->cost.startup; and + run_cost += 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 += foreignrel->reltarget->cost.startup; and + run_cost += 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 += foreignrel->reltarget->cost.per_tuple * rows; } + /* + * 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 >= 0 && + fpinfo->rel_total_cost >= 0); + + startup_cost += foreignrel->reltarget->cost.startup; + run_cost += 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 -- Antonin Houska Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26, A-2700 Wiener Neustadt Web: https://www.cybertec-postgresql.com
