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

Incorrect Column Reference in ORDER BY Subquery Plan in vtgate #16110

Closed
systay opened this issue Jun 11, 2024 · 0 comments · Fixed by #16049
Closed

Incorrect Column Reference in ORDER BY Subquery Plan in vtgate #16110

systay opened this issue Jun 11, 2024 · 0 comments · Fixed by #16049

Comments

@systay
Copy link
Collaborator

systay commented Jun 11, 2024

Issue Description

Problem

When performing an ORDER BY on a subquery, the vtgate planner generates a plan that does not work.

Example

For the following query:

SELECT (SELECT col FROM user LIMIT 1) AS a 
FROM user 
JOIN user_extra 
ORDER BY a;

The planner produces a plan containing this snippet:

{
  "OperatorType": "UncorrelatedSubquery",
  "Variant": "PulloutValue",
  "PulloutVars": [
    "__sq1"
  ],
  "Inputs": [
    {
      "InputName": "SubQuery",
      "OperatorType": "Limit",
      "Count": "1",
      "Inputs": [
        {
          "OperatorType": "Route",
          "Variant": "Scatter",
          "Keyspace": {
            "Name": "user",
            "Sharded": true
          },
          "FieldQuery": "select col from `user` where 1 != 1",
          "Query": "select col from `user` limit 1",
          "Table": "`user`"
        }
      ]
    },
    {
      "InputName": "Outer",
      "OperatorType": "Route",
      "Variant": "Scatter",
      "Keyspace": {
        "Name": "user",
        "Sharded": true
      },
      "FieldQuery": "select :__sq1 as __sq1, weight_string(:__sq1) from `user` where 1 != 1",
      "OrderBy": "(0|1) ASC",
      "Query": "select :__sq1 as __sq1, weight_string(:__sq1) from `user` order by __sq1 asc",
      "Table": "`user`"
    }
  ]
}

Issue

In the query sent to the outer side of the subquery, the plan uses the column name __sq1 instead of the argument :__sq1, which would be the correct plan.

Result

This discrepancy results in a query that fails on MySQL, as no such column (__sq1) can be found.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant