Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote:
> (2019/03/01 20:00), Antonin Houska wrote:
> > Etsuro Fujita<fujita.ets...@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
