(2019/03/02 1:14), Antonin Houska wrote:
> Etsuro Fujita<fujita.etsuro@lab.ntt.co.jp> wrote:
>> (2019/03/01 20:00), Antonin Houska wrote:
>> 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?
Yeah, I think so.
Best regards,
Etsuro Fujita
