Re: BUG #18652: Planner can not find pathkey item to sort for query with expression and expression index
От | Richard Guo |
---|---|
Тема | Re: BUG #18652: Planner can not find pathkey item to sort for query with expression and expression index |
Дата | |
Msg-id | CAMbWs493zyKNN2nJmYWpcNGn9N+D3D+1qavjFRMvRGR55UWrhA@mail.gmail.com обсуждение исходный текст |
Ответ на | 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>) |
Ответы |
Re: BUG #18652: Planner can not find pathkey item to sort for query with expression and expression index
|
Список | pgsql-bugs |
On Thu, Oct 10, 2024 at 12:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > So it's specific to MergeAppend and it's been wrong from day zero. > That makes me think it's probably not find_computable_ec_member's > fault directly. Fixing it there might be the most expedient answer, > but I feel like first we should drill down a bit further to understand > the root problem. I'm too tired to do more tonight though. Usually a relation's targetlist should include only Vars and PHVs during this phase. I think this may be the rationale behind find_computable_ec_member matching only Vars and quasi-Vars. However, for a child rel, when we copy the parent's targetlist with appropriate substitution, we may generate arbitrary expressions, such as an OpExpr for 'i + 1' in this case. We have a note in the comments in set_append_rel_size saying that * Code that might be looking at an appendrel child must cope with * such. It seems to me that find_computable_ec_member does not get this memo. Alternatively, can we wrap non-var expressions in a childrel's targetlist into PHVs, so that we do not need special handling for an appendrel child? I have not tried this though. Thanks Richard
В списке pgsql-bugs по дате отправления: