Re: Problems with plan estimates in postgres_fdw

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

> (2019/03/01 20:00), Antonin Houska wrote:
> > Etsuro Fujita<fujita.etsuro@lab.ntt.co.jp>  wrote:

> > I used gdb to help me understand, however the condition
> >
> > 	if (fpextra&&  !IS_UPPER_REL(foreignrel))
> >
> > never evaluated to true with the query above.
> 
> Sorry, my explanation was not enough again, but I showed that query ("SELECT
> a+b, random() FROM foreign_table GROUP BY a+b ORDER BY a+b;") to explain why
> the following code bit is needed:
> 
> +       /*
> +        * If this includes an UPPERREL_ORDERED step, the given target, which
> +        * would be the final target to be applied to the resulting path,
> might
> +        * have different expressions from the underlying relation's reltarget
> +        * (see make_sort_input_target()); adjust tlist eval costs.
> +        */
> +       if (fpextra&&  fpextra->target != foreignrel->reltarget)
> +       {
> +               QualCost        oldcost = foreignrel->reltarget->cost;
> +               QualCost        newcost = fpextra->target->cost;
> +
> +               startup_cost += newcost.startup - oldcost.startup;
> +               total_cost += newcost.startup - oldcost.startup;
> +               total_cost += (newcost.per_tuple - oldcost.per_tuple) * rows;
> +       }

Maybe I undestand now. Do the expressions (newcost.* - oldcost.*) reflect the
fact that, for the query

	SELECT a+b, random() FROM foreign_table GROUP BY a+b ORDER BY a+b;

the UPPERREL_ORDERED stage only needs to evaluate the random() function
because (a + b) was already evaluated during the UPPERREL_GROUP_AGG stage?

-- 
Antonin Houska
https://www.cybertec-postgresql.com