Re: BUG #18652: Planner can not find pathkey item to sort for query with expression and expression index
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Richard Guo <guofenglinux@gmail.com>, exclusion@gmail.com,
pgsql-bugs@lists.postgresql.org
Date: 2024-10-12T19:13:47Z
Lists: pgsql-bugs
Andrei Lepikhov <lepihov@gmail.com> writes: > On 12/10/2024 03:59, Tom Lane wrote: >> I wonder whether we're doing more work here than we really need to. >> If the underlying table t1 has columns i and j, and we have an EC >> member that references t1.j while the tlist only mentions t1.i, >> wouldn't it still work to add t1.j to the tlist? So maybe groveling >> through the tlist members is unnecessary and we only need to be >> performing some kind of relation-level check on whether all the >> required relations are included in the input. > I'm not sure I understand this point. Do you mean something like > attached? More or less, yeah, although passing the tlist rather than some more-direct representation of the current relation's relids looks weird once you think of it this way. After thinking about this for awhile though, I suspect it is only sure to work for appendrel children (where an EC match should be guaranteed to exist, by construction). Maybe we could use this simplified approach if we know we're considering an appendrel child, but I doubt it's worth having two code paths. regards, tom lane
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