Re: BUG #18652: Planner can not find pathkey item to sort for query with expression and expression index

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

In response to

Browse pgsql-bugs by date

  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