-
Notifications
You must be signed in to change notification settings - Fork 127
internal/rule: fix squashjoins rule to squash projections properly too #338
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
Conversation
internal/rule/squashjoins.go
Outdated
func squashProjects(parent, child *plan.Project) (sql.Node, error) { | ||
projections := []sql.Expression{} | ||
for _, expr := range parent.Expressions() { | ||
parentField, ok := expr.(*expression.GetField) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If an expression is a literal, will it fail? Example:
SELECT count(1),1 , refs.repository_id
FROM refs
NATURAL JOIN commits
NATURAL JOIN commit_blobs
WHERE refs.ref_name = 'HEAD'
GROUP BY refs.repository_id
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That query doesn't work because of how the GroupBy
is implemented right now. It only allows expressions in the select which are aggregations or are in the group by too, not because of the changes in this PR.
The following query, for example. does work:
MySQL [(none)]> SELECT 1,refs.repository_id FROM refs NATURAL JOIN commits NATURAL JOIN commit_blobs WHERE refs.ref_name = 'HEAD' limit 10;
+------+---------------+
| 1 | repository_id |
+------+---------------+
| 1 | enry |
| 1 | enry |
| 1 | enry |
| 1 | enry |
| 1 | enry |
| 1 | enry |
| 1 | enry |
| 1 | enry |
| 1 | enry |
| 1 | enry |
+------+---------------+
10 rows in set (0.02 sec)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
then, how can we reach that error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry @ajnavarro, I think I'm not understanding you. Do you mean that if a literal appears in the projection the query should fail? Anyway that's something not related to this PR, I guess.
Should I open an issue for it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm trying to understand when this error will be thrown.
As I can see on the squashProjects
you are getting the expressions on the projection and checking if the type is a Getfield
expression. If not, you are throwing an error.
There are some cases when a projection can contain other expressions than GetField
(per example, a Function
or a Literal
), and that is not necessarily an error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤓 Now I see what you mean. The thing is that the projections to squash coming from the replacement of natural joins by inner joins, and those projections only contains GetFields
. That's the reason because the chained projections appear, so functions and literals written in a query aren't going to be squashed.
@ajnavarro I already committed the change to not throw an error |
internal/rule/squashjoins.go
Outdated
} | ||
|
||
squashedProject, err := squashProjects(project, child) | ||
if err != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other error than errWrongProjection can happen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, cannot, but this code is a little bit misleading. Maybe instead of return squashedProject and err we should return squasedProject and ok
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
2917d49
to
ceb33f3
Compare
@mcarmonaa can you rebase and merge please? |
Signed-off-by: Manuel Carmona <manu.carmona90@gmail.com>
Signed-off-by: Manuel Carmona <manu.carmona90@gmail.com>
ceb33f3
to
015bbfa
Compare
Fixes #322
The bug came because the projects nodes over inner joins weren't squashed, so they stayed chained and pointing to wrong field indexes after the table squashing
Now the project nodes are squashed too, so it works properly:
Signed-off-by: Manuel Carmona manu.carmona90@gmail.com