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
I saw a few queries flying around with field == "*" syntax. In general, I think we should direct users to direct == null or != null checking, but sometimes we see usage patterns from KQL seep in.
Under the hood field == "*" gets converted to wildcard(field, "*"), which eventually turns into an AST for "like": Like(Source(), Field("field"), "%").
I think somewhere in the optimizer to we should convert this to IsNotNull which should be more performant.
The text was updated successfully, but these errors were encountered:
We have some optimizations internally when parsing a search request that rewrites a query like field:* into an exists query for the field. However we don't apply this optimization to wildcard and prefix queries, only in query_string.
So I don't know what is the step to move from wildcard(field, "*") to Like(Source(), Field("field"), "%") but for the search layer, we should be able to optimize the first case, wildcard(field, "*").
costin
added a commit
to costin/elasticsearch
that referenced
this issue
Sep 21, 2020
Uh oh!
There was an error while loading. Please reload this page.
I saw a few queries flying around with
field == "*"
syntax. In general, I think we should direct users to direct== null
or!= null
checking, but sometimes we see usage patterns from KQL seep in.Under the hood
field == "*"
gets converted towildcard(field, "*")
, which eventually turns into an AST for "like":Like(Source(), Field("field"), "%")
.I think somewhere in the optimizer to we should convert this to
IsNotNull
which should be more performant.The text was updated successfully, but these errors were encountered: