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