Re: BUG #18652: Planner can not find pathkey item to sort for query with expression and expression index
От | Tom Lane |
---|---|
Тема | Re: BUG #18652: Planner can not find pathkey item to sort for query with expression and expression index |
Дата | |
Msg-id | 3322031.1728760427@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #18652: Planner can not find pathkey item to sort for query with expression and expression index (PG Bug reporting form <noreply@postgresql.org>) |
Список | 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
В списке pgsql-bugs по дате отправления: