On 10.10.2024 13:23, Andrei Lepikhov wrote:
> On 10/10/24 16:02, Tender Wang wrote:
>>
>>
>> Andrei Lepikhov <lepihov@gmail.com <mailto:lepihov@gmail.com>> 于2024年
>> > 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
>> insert the Sort node?
> Before inserting the Sort node, we must identify the column
> corresponding to each path key. And here is the problem: IndexScan has
> two elements in the target list, but SeqScan has only one. It already
> looks strange to me. How do we UNION two sources with different
> numbers of resulting columns? It seems to me we have a bug under the
> Append node.
>
Maybe a mistake exists at the stage of creating a sequential scan?
Because the subpath of the MergeAppend path does not have any elements
in pathkeys, although the pasthtarget has one element and this
expression wasn't involved anywhere?
I honestly don’t understand at what stage this expression i+1 appears:
SELECT i + 0 AS c FROM (SELECT i FROM t UNION ALL SELECT i + 1 FROM t)
--
Regards,
Alena Rybakina
Postgres Professional
