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

SQL: date and numeric comparison are translated to separate range queries #30017

Closed
elasticmachine opened this issue Apr 24, 2018 · 0 comments
Closed

Comments

@elasticmachine
Copy link
Collaborator

Original comment by @astefan:

For a query like:

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):

...
  "query": {
    "bool": {
      "filter": [
        {
          "bool": {
            "filter": [
              {
                "bool": {
                  "filter": [
                    {
                      "bool": {
                        "must_not": [
                          {
                            "term": {
                              "name.keyword": {
                                "value": "NULL",
                                "boost": 1
                              }
                            }
                          }
                        ],
                        "adjust_pure_negative": true,
                        "boost": 1
                      }
                    },
                    {
                      "range": {
                        "price": {
                          "from": 10,
                          "to": null,
                          "include_lower": true,
                          "include_upper": false,
                          "boost": 1
                        }
                      }
                    }
                  ],
                  "adjust_pure_negative": true,
                  "boost": 1
                }
              },
              {
                "range": {
                  "price": {
                    "from": null,
                    "to": 200,
                    "include_lower": false,
                    "include_upper": true,
                    "boost": 1
                  }
                }
              }
            ],
            "adjust_pure_negative": true,
            "boost": 1
          }
        },
...
costin added a commit to costin/elasticsearch that referenced this issue Apr 30, 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.

Fix elastic#30017
costin added a commit that referenced this issue May 2, 2018
* 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

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

No branches or pull requests

2 participants