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?
Yeah, I'm also curious why only cost Sort but not adding Sort node in create_merge_append_path().
The comments say that " We'll need to insert a Sort node, so include cost for that". Does another place
