From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andrei Lepikhov <lepihov(at)gmail(dot)com>, 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-12 04:13:51 |
Message-ID: | CAMbWs48t0LBsPf4bZ9UdGousuTNmrauD_01NrauRFXTrwt++Jg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Sat, Oct 12, 2024 at 4:59 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> This means that it will work so long as all of the Vars needed by the
> EC member expression are available from the plan node's input, which
> they surely are if they are referenced in the existing tlist. That
> is, even if we wanted to compute "t2.i + 2" it'd be fine.
>
> (This would fall down perhaps if there are volatile functions in
> the sort expression, but I believe we already reject using volatile
> expressions for merge append, so it's not a problem.)
>
> So I conclude that Andrei's patch will fix it, although I don't like
> the way that that requires (potentially) multiple re-executions of
> pull_var_clause. I think we should refactor the code to avoid that,
> which actually ends up being less code, as in the attached draft.
+1. I think it's conceptually correct that if 'Var_A + 2' is
computable in a plan node's targetlist, then 'Var_A + 1' must be also
computable in the same targetlist.
Thanks
Richard
From | Date | Subject | |
---|---|---|---|
Next Message | Andrei Lepikhov | 2024-10-12 06:05:25 | Re: BUG #18652: Planner can not find pathkey item to sort for query with expression and expression index |
Previous Message | Andrei Lepikhov | 2024-10-12 01:53:19 | Re: Question of Parallel Hash Join on TPC-H Benchmark |