Richard Guo writes:
> On Thu, Feb 23, 2023 at 4:50 AM Tom Lane wrote:
>> Less-hasty v2 patch attached.
> I think the patch is in good shape now.
Pushed, thanks for reviewing!
regards, tom lane
On Thu, Feb 23, 2023 at 4:50 AM Tom Lane wrote:
> I thought about this and decided that it's not really a problem.
> have_relevant_joinclause is just a heuristic, and I don't think we
> need to prioritize forming a join if the only relevant clauses look
> like this. We won't be able to use such
Richard Guo writes:
> On Mon, Feb 20, 2023 at 4:56 AM Tom Lane wrote:
>> * I suspect the other use of get_common_eclass_indexes, in
>> have_relevant_eclass_joinclause, is broken as well.
> It seems have_relevant_joinclause is broken for the presented case. It
> does not get a change to call
On Mon, Feb 20, 2023 at 4:56 AM Tom Lane wrote:
> * I suspect the other use of get_common_eclass_indexes, in
> have_relevant_eclass_joinclause, is broken as well.
It seems have_relevant_joinclause is broken for the presented case. It
does not get a change to call
Richard Guo writes:
> ... As we can see, the join qual 't2.a = t2.b' disappears in the plan, and
> that results in the wrong query results.
Ugh.
> I did some dig and here is what happened. Firstly both sides of qual
> 't2.a = t2.b' could be nulled by the OJ t1/t2 and they are marked so in
>
I came across $subject on HEAD and here is the query I'm using.
create table t1 (a int, b int);
create table t2 (a int, b int);
create table t3 (a int, b int);
insert into t1 values (1, 1);
insert into t2 values (2, 200);
insert into t3 values (3, 3);
# select * from t1 left join t2 on true,
