Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for SQL Natural Join #4863

Merged
merged 2 commits into from
Jan 10, 2023
Merged

Support for SQL Natural Join #4863

merged 2 commits into from
Jan 10, 2023

Conversation

Jefffrey
Copy link
Contributor

@Jefffrey Jefffrey commented Jan 9, 2023

Which issue does this PR close?

Closes #117

Rationale for this change

What changes are included in this PR?

Support for planning sql natural join, which simply gets turned into a USING join based on the common columns (checked via name only), and if no common columns found then becomes a cross join.

Are these changes tested?

Added to sql integration_test.rs

Are there any user-facing changes?

@github-actions github-actions bot added the sql SQL Planner label Jan 9, 2023
Err(DataFusionError::NotImplemented(
"NATURAL JOIN is not supported (https://issues.apache.org/jira/browse/ARROW-10727)".to_string(),
))
// TODO: what if no common join cols? -> becomes cross join
Copy link
Member

@jackwener jackwener Jan 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// TODO: what if no common join cols? -> becomes cross join

Yes, we should convert it to cross-join.

like pg:

-- create
CREATE TABLE a (
  id INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  dept TEXT NOT NULL
);
CREATE TABLE b (
  id1 INTEGER PRIMARY KEY,
  name1 TEXT NOT NULL,
  dept1 TEXT NOT NULL
);

-- insert
INSERT INTO a VALUES (0001, 'Clark', 'Sales');
INSERT INTO b VALUES (0001, 'Clark', 'Sales');
INSERT INTO a VALUES (0002, 'Ava', 'Sales');
INSERT INTO b VALUES (0002, 'Ava', 'Sales');


-- fetch 
SELECT * FROM a natural join b;

 id | name  | dept  | id1 | name1 | dept1 
----+-------+-------+-----+-------+-------
  1 | Clark | Sales |   1 | Clark | Sales
  1 | Clark | Sales |   2 | Ava   | Sales
  2 | Ava   | Sales |   1 | Clark | Sales
  2 | Ava   | Sales |   2 | Ava   | Sales
(4 rows)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, I think that's been implemented, just forgot to remove the TODOs

Comment on lines +153 to +160
let keys: Vec<Column> = right
.schema()
.fields()
.iter()
.map(|f| f.field().name())
.filter(|f| left_cols.contains(f))
.map(Column::from_name)
.collect();
Copy link
Member

@jackwener jackwener Jan 9, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please notice qualifier. Field can own a qualifier and also don't own a qualifier

For example,
t1: |t1.a|t1.b|c| (we can meet c instead of t1.c)

We also need add test to consider it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I follow, are you suggesting to consider the qualifier when checking for common columns? My understanding is that when joining two different tables they should have different qualifiers anyway.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I follow, are you suggesting to consider the qualifier when checking for common columns? My understanding is that when joining two different tables they should have different qualifiers anyway.

Look like current implementation is ok. field.name() don't use qualifier, so this Problem don't exist

@@ -395,6 +395,54 @@ fn join_with_ambiguous_column() {
quick_test(sql, expected);
}

#[test]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@jackwener jackwener self-assigned this Jan 10, 2023
Copy link
Member

@jackwener jackwener left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Look great to me, thanks @Jefffrey

Copy link
Contributor

@alamb alamb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM -- thanks @Jefffrey and @JasonLi-cn

@alamb alamb merged commit 556282a into apache:master Jan 10, 2023
@ursabot
Copy link

ursabot commented Jan 10, 2023

Benchmark runs are scheduled for baseline = 1eb46df and contender = 556282a. 556282a is a master commit associated with this PR. Results will be available as each benchmark for each run completes.
Conbench compare runs links:
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on ec2-t3-xlarge-us-east-2] ec2-t3-xlarge-us-east-2
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on test-mac-arm] test-mac-arm
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on ursa-i9-9960x] ursa-i9-9960x
[Skipped ⚠️ Benchmarking of arrow-datafusion-commits is not supported on ursa-thinkcentre-m75q] ursa-thinkcentre-m75q
Buildkite builds:
Supported benchmarks:
ec2-t3-xlarge-us-east-2: Supported benchmark langs: Python, R. Runs only benchmarks with cloud = True
test-mac-arm: Supported benchmark langs: C++, Python, R
ursa-i9-9960x: Supported benchmark langs: Python, R, JavaScript
ursa-thinkcentre-m75q: Supported benchmark langs: C++, Java

@Jefffrey Jefffrey deleted the sql_natural_join branch January 10, 2023 08:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sql SQL Planner
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add SQL support for NATURAL JOIN
4 participants