From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
Cc: | Richard Guo <guofenglinux(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 19:13:47 |
Message-ID: | 3322031.1728760427@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Andrei Lepikhov <lepihov(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrei Lepikhov | 2024-10-13 00:01:29 | Re: Question of Parallel Hash Join on TPC-H Benchmark |
Previous Message | Ba Jinsheng | 2024-10-12 18:11:04 | Re: Question of Parallel Hash Join on TPC-H Benchmark |