Closed systay closed 6 months ago
Apparently this is already fixed. I just tested out and with the latest planner code -
{
"QueryType": "SELECT",
"Original": "select 1, (select -1 from main.user) a from music order by a",
"Instructions": {
"OperatorType": "UncorrelatedSubquery",
"Variant": "PulloutValue",
"PulloutVars": [
"__sq1"
],
"Inputs": [
{
"InputName": "SubQuery",
"OperatorType": "Route",
"Variant": "Unsharded",
"Keyspace": {
"Name": "main",
"Sharded": false
},
"FieldQuery": "select -1 from `user` where 1 != 1",
"Query": "select -1 from `user`",
"Table": "`user`"
},
{
"InputName": "Outer",
"OperatorType": "Route",
"Variant": "Scatter",
"Keyspace": {
"Name": "user",
"Sharded": true
},
"FieldQuery": "select :__sq1 as __sq1, weight_string(:__sq1) from music where 1 != 1",
"OrderBy": "(0|1) ASC",
"Query": "select :__sq1 as __sq1, weight_string(:__sq1) from music order by __sq1 asc",
"Table": "music"
}
]
},
"TablesUsed": [
"main.user",
"user.music"
]
}
When planning a query that contains an ORDER BY on a subquery, the current Vitess planner produces a bad plan:
As can be seen in the second query we send down, it contains the subquery that should have been sent in the other route.