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

Andrei Lepikhov <lepihov@gmail.com>

From: Andrei Lepikhov <lepihov@gmail.com>
To: Richard Guo <guofenglinux@gmail.com>
Cc: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2024-10-10T06:50:01Z
Lists: pgsql-bugs
On 10/10/24 10:52, Richard Guo wrote:
> On Thu, Oct 10, 2024 at 5:43 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It looks like we are generating a Path tree in which one of the
>> inputs to a MergeAppend is a plain unsorted seqscan, which'd
>> be all right except it doesn't expose the required sort value
>> in its targetlist.
> 
> Correct.  In addition, find_computable_ec_member() fails to find a
> computable expression from its targetlist.
> For the indexscan path, find_computable_ec_member() is able to find
> (t.i + 0) which can be computed from its tlist item 't.i'.
> 
> For the seqscan path, though, find_computable_ec_member() is not able
> to find ((t_1.i + 1) + 0) from its tlist item '(t_1.i + 1)'.
> 
> I think this is because find_computable_ec_member() only tries to
> match Vars.  Maybe we should teach it to also match OpExprs?
Looking into that case, I don't understand only one thing:
generate_orderedappend_paths decided to try MergeAppend; the 
create_append_path routine added the Sort cost,  but the Sort node 
itself wasn't added. Maybe the origin problem is the lack of feasibility 
examinations?

-- 
regards, Andrei Lepikhov




Commits

  1. Correctly identify which EC members are computable at a plan node.

  2. Support MergeAppend plans, to allow sorted output from append relations.