# Elasticsearch Wildcard fieldtype has slow performance for wildcard queries

**URL:** <https://discuss.elastic.co/t/elasticsearch-wildcard-fieldtype-has-slow-performance-for-wildcard-queries/259662>\
**Category:** Elasticsearch\
**Created:** [December 26, 2020, 1:21pm UTC](https://discuss.elastic.co/t/elasticsearch-wildcard-fieldtype-has-slow-performance-for-wildcard-queries/259662 "2020-12-26T13:21:36Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Chris\_Doman](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/chris_doman/32/81413_2.png) [@Chris\_Doman](https://discuss.elastic.co/u/Chris_Doman)\
**Post date:** [December 26, 2020, 1:21pm UTC](https://discuss.elastic.co/t/elasticsearch-wildcard-fieldtype-has-slow-performance-for-wildcard-queries/259662/1 "2020-12-26T13:21:36Z")

</div>

I'm testing the new ElasticSearch WildCard field type ([https://www.elastic.co/blog/find-strings-within-strings-faster-with-the-new-elasticsearch-wildcard-field](https://www.elastic.co/blog/find-strings-within-strings-faster-with-the-new-elasticsearch-wildcard-field)) that is supposed to offer better wildcard queries.

Strangely, it seems to be slower for wildcard queries than the default text field.

Is this expected behaviour, or am I doing something wrong?

I am searching about approx. 500,000 rows of log data.

With the default text type (though only searches over first 256 chars due to ignore\_above):

```auto
 "result" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        }

time curl -X GET "localhost:9200/text-index/_count?pretty" -H "Content-Type: application/json" -d'{ "query": { "wildcard": { "result": "*dfdskfjdskofsdjf*" } } } '

```

= 3.2 Seconds

With the new wildcard field type:

```auto
"result" : {
          "type" : "wildcard"
        }

time curl -X GET "localhost:9200/wildcard-index/_count?pretty" -H "Content-Type: application/json" -d'{ "query": { "wildcard": { "result": "*dfdskfjdskofsdjf*" } } } '

```

= 24.95 seconds

---

<div class="post-metadata">

**Author:** ![Mark\_Harwood](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mark_harwood/32/10538_2.png) [@Mark\_Harwood](https://discuss.elastic.co/u/Mark_Harwood)\
**Post date:** [December 26, 2020, 10:24pm UTC](https://discuss.elastic.co/t/elasticsearch-wildcard-fieldtype-has-slow-performance-for-wildcard-queries/259662/2 "2020-12-26T22:24:31Z")

</div>

What’s the cardinality of values in this field?  
As the flowchart at the end of [this blog](https://www.elastic.co/blog/find-strings-within-strings-faster-with-the-new-elasticsearch-wildcard-field) advises - the wildcard field is designed for use on fields with millions of unique values.

Keyword fields get bogged down by large numbers of unique terms while wildcard fields will be bogged down by large numbers of docs that share a common term (ie low cardinality vs high cardinality fields.)

---

<div class="post-metadata">

**Author:** ![Chris\_Doman](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/chris_doman/32/81413_2.png) [@Chris\_Doman](https://discuss.elastic.co/u/Chris_Doman)\
**Post date:** [December 28, 2020, 2:52pm UTC](https://discuss.elastic.co/t/elasticsearch-wildcard-fieldtype-has-slow-performance-for-wildcard-queries/259662/3 "2020-12-28T14:52:49Z")

</div>

Mostly unique values but there is repetition of words within them - typical log data.  
I've ended up using a default text field instead of wildcard, with ngram tokenizer

---

<div class="post-metadata">

**Author:** ![Mark\_Harwood](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mark_harwood/32/10538_2.png) [@Mark\_Harwood](https://discuss.elastic.co/u/Mark_Harwood)\
**Post date:** [December 28, 2020, 3:14pm UTC](https://discuss.elastic.co/t/elasticsearch-wildcard-fieldtype-has-slow-performance-for-wildcard-queries/259662/4 "2020-12-28T15:14:53Z")

</div>

> [@Chris\_Doman](#):
>
> Mostly unique values

Thanks. I am keen to diagnose the performance further if you can help with these 2 questions:

1. On the keyword field, what is the value of this aggregation?

```GET
{
  "size":0,
  "aggs":{
    "numTerms":{
      "cardinality": {
        "field": "x"
      }
    }
  }
}

```

1. How many documents matched your wildcard query?

---

<div class="post-metadata">

**Author:** ![Mark\_Harwood](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/mark_harwood/32/10538_2.png) [@Mark\_Harwood](https://discuss.elastic.co/u/Mark_Harwood)\
**Post date:** [December 29, 2020, 9:31am UTC](https://discuss.elastic.co/t/elasticsearch-wildcard-fieldtype-has-slow-performance-for-wildcard-queries/259662/5 "2020-12-29T09:31:42Z")

</div>

Just reviewing this topic again and a couple of things jumped out:

> [@Chris\_Doman](#):
>
> With the default text type (though only searches over first 256 chars due to ignore\_above)

Keyword values greater than 256 are completely ignored, not truncated. They are completely missing from the index.

Your example request was searching the text field and not the keyword field which would need to be queried by the ‘result.keyword’ name.  
Querying a text field may be faster (fewer unique terms in the index) but your query scope is different - you’re searching within the confines of single terms/words rather than for any possible character sequence in the original value. The blog highlights why word-based text indexes are of less use in machine generated content where there’s no common agreement between searcher and search engine as to what constitutes a word.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [January 26, 2021, 9:31am UTC](https://discuss.elastic.co/t/elasticsearch-wildcard-fieldtype-has-slow-performance-for-wildcard-queries/259662/6 "2021-01-26T09:31:43Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.