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

Tender Wang <tndrwang@gmail.com>

From: Tender Wang <tndrwang@gmail.com>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: Richard Guo <guofenglinux@gmail.com>, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2024-10-10T09:02:16Z
Lists: pgsql-bugs
Andrei Lepikhov <lepihov@gmail.com> 于2024年10月10日周四 14:50写道:

> 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?
>
>
Yeah, I'm also curious why only cost Sort but not adding Sort node in
create_merge_append_path().
The comments say that " We'll need to insert a Sort node, so include cost
for that".  Does another place
insert the Sort node?

-- 
Thanks,
Tender Wang

Commits

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

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