Bug(planner): wrong output in hash join

[xudong963]

The result is not correct in my case:

create table t1(a int, b int);
create table t2(a int, b int);
create table t3(a int, b int);

insert into t1 select number, number+1 from numbers(100000000);
insert into t2 select number, number+1 from numbers(20000000);
insert into t3 select number, number+1 from numbers(10000000);

select count(*) from t1 inner join t2 on t1.a=t2.a inner join t3 on t2.b=t3.b;

+----------+
| COUNT(*) |
+----------+
|        0 |
+----------+
1 row in set (6.45 sec)

Result should be:

┌──count()─┐
│ 10000000 │
└──────────┘

Originally posted by @BohuTANG in #5497 (comment)

[sundy-li]

fn visit_read_data_source(&mut self, plan: &ReadDataSourcePlan) -> Result<Pipeline> {
        // Bind plan partitions to context.
 self.ctx.try_set_partitions(plan.parts.clone())?;

I believe it's because we set the partition to the ctx. Since we read two different tables, the partition info are overridden.

cc @zhang2014

:) select count(*) from (select to_int32(a) as a from t1 order by a limit 10) t1 inner join (select to_int32(number) as a from numbers(10)) t2 on t1.a=t2.a;
ERROR 1105 (HY000): Code: 1015, displayText = Cannot downcast from PartInfo to FusePartInfo. (while in processor thread 5).

[leiysky]

@sundy-li This should have been fixed by https://github.com/datafuselabs/databend/blob/eb07b393c769b152ef742c0b8f91032de5c98562/query/src/sql/exec/mod.rs#L191

[zhang2014]

@sundy-li This should have been fixed by

https://github.com/datafuselabs/databend/blob/eb07b393c769b152ef742c0b8f91032de5c98562/query/src/sql/exec/mod.rs#L310-L332

We still use self.ctx in build_physical_scan CC: @leiysky

[leiysky]

@zhang2014 You are right, I will fix this in #5538 as well.

[leiysky]

I missed the related commit in #5538, thus I opened #5539 to fix this.