Re: BUG #18652: Planner can not find pathkey item to sort for query with expression and expression index
Andrei Lepikhov <lepihov@gmail.com>
From: Andrei Lepikhov <lepihov@gmail.com>
To: Richard Guo <guofenglinux@gmail.com>
Cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org,
Tom Lane <tgl@sss.pgh.pa.us>
Date: 2024-10-10T06:50:01Z
Lists: pgsql-bugs
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
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