On 10/10/24 10:52, Richard Guo wrote:
> On Thu, Oct 10, 2024 at 5:43 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It looks like we are generating a Path tree in which one of the
>> inputs to a MergeAppend is a plain unsorted seqscan, which'd
>> be all right except it doesn't expose the required sort value
>> in its targetlist.
> 
> Correct.  In addition, find_computable_ec_member() fails to find a
> computable expression from its targetlist.
> For the indexscan path, find_computable_ec_member() is able to find
> (t.i + 0) which can be computed from its tlist item 't.i'.
> 
> For the seqscan path, though, find_computable_ec_member() is not able
> to find ((t_1.i + 1) + 0) from its tlist item '(t_1.i + 1)'.
> 
> I think this is because find_computable_ec_member() only tries to
> match Vars.  Maybe we should teach it to also match OpExprs?
Looking into that case, I don't understand only one thing:
generate_orderedappend_paths decided to try MergeAppend; the 
create_append_path routine added the Sort cost,  but the Sort node 
itself wasn't added. Maybe the origin problem is the lack of feasibility 
examinations?
-- 
regards, Andrei Lepikhov