From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18652: Planner can not find pathkey item to sort for query with expression and expression index |
Date: | 2024-10-10 11:57:22 |
Message-ID: | CAMbWs493zyKNN2nJmYWpcNGn9N+D3D+1qavjFRMvRGR55UWrhA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Thu, Oct 10, 2024 at 12:34 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ba Jinsheng | 2024-10-10 14:11:49 | Question of Parallel Hash Join on TPC-H Benchmark |
Previous Message | Alena Rybakina | 2024-10-10 10:41:01 | Re: BUG #18652: Planner can not find pathkey item to sort for query with expression and expression index |