Re: Problems with plan estimates in postgres_fdw

Поиск
Список
Период
Сортировка
От Antonin Houska
Тема Re: Problems with plan estimates in postgres_fdw
Дата
Msg-id 30524.1550499671@localhost
обсуждение исходный текст
Ответ на Re: Problems with plan estimates in postgres_fdw  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Ответы Re: Problems with plan estimates in postgres_fdw  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Список pgsql-hackers
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.
>
> 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Progress reporting for pg_verify_checksums
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Reporting script runtimes in pg_regress