Re: BUG #18652: Planner can not find pathkey item to sort for query with expression and expression index
Alena Rybakina <a.rybakina@postgrespro.ru>
From: Alena Rybakina <a.rybakina@postgrespro.ru>
To: Andrei Lepikhov <lepihov@gmail.com>, Tender Wang <tndrwang@gmail.com>
Cc: Richard Guo <guofenglinux@gmail.com>, exclusion@gmail.com,
pgsql-bugs@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2024-10-10T10:41:01Z
Lists: pgsql-bugs
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
Commits
-
Correctly identify which EC members are computable at a plan node.
- 9f954177b1eb 18.0 landed
- 76de4b182cad 13.17 landed
- 64635c8af92d 16.5 landed
- 54889ea64baa 17.1 landed
- 4f3bccbaaeb4 15.9 landed
- 4ca708eb3588 14.14 landed
-
Support MergeAppend plans, to allow sorted output from append relations.
- 11cad29c9152 9.1.0 cited