You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
POST /_xpack/sql/translate
{
"query":"SELECT name.keyword FROM library WHERE name!='NULL' AND release_date >= '2011-06-02' AND release_date <= '2011-06-02' AND match(author,'dan')"
}
or (with numerics):
POST /_xpack/sql/translate
{
"query":"SELECT name.keyword FROM library WHERE name!='NULL' AND price >= 10 AND price <= 200 AND match(author,'dan')"
}
The translated query uses individual range queries for the lower and upper limits even though the field being used in the query is the same and an optimization like {"range":{"price":{"from":10,"to":200,"include_lower":true,"include_upper":true,"boost":1}}} can be used instead. For the reference, this is the translated query at the moment (irrelevant parts not provided):
Rewrote optimization rule for combining ranges by improving the
detection of binary comparisons in a tree to better combine
them in a range, regardless of their place inside an expression.
Additionally, improve the comparisons of Numbers of different types
Also, improve reassembly of conjunction/disjunction into balanced
trees.
Fixelastic#30017
* SQL: Reduce number of ranges generated for comparisons
Rewrote optimization rule for combining ranges by improving the
detection of binary comparisons in a tree to better combine
them in a range, regardless of their place inside an expression.
Additionally, improve the comparisons of Numbers of different types
Also, improve reassembly of conjunction/disjunction into balanced
trees.
Do not promote BinaryComparisons to Ranges since it introduces NULL
boundaries and thus a corner-case that needs too much handling
Compare BinaryComparisons directly between themselves and to Ranges
Fix#30017
costin
added a commit
to costin/elasticsearch
that referenced
this issue
May 2, 2018
Rewrote optimization rule for combining ranges by improving the
detection of binary comparisons in a tree to better combine
them in a range, regardless of their place inside an expression.
Additionally, improve the comparisons of Numbers of different types
Also, improve reassembly of conjunction/disjunction into balanced
trees.
Do not promote BinaryComparisons to Ranges since it introduces NULL
boundaries and thus a corner-case that needs too much handling
Compare BinaryComparisons directly between themselves and to Ranges
Fixelastic#30017
Original comment by @astefan:
For a query like:
or (with numerics):
The translated query uses individual
range
queries for the lower and upper limits even though the field being used in the query is the same and an optimization like{"range":{"price":{"from":10,"to":200,"include_lower":true,"include_upper":true,"boost":1}}}
can be used instead. For the reference, this is the translated query at the moment (irrelevant parts not provided):The text was updated successfully, but these errors were encountered: