# Wildcard query performance

**URL:** <https://discuss.elastic.co/t/wildcard-query-performance/4348>\
**Category:** Elasticsearch\
**Created:** [May 4, 2011, 5:10pm UTC](https://discuss.elastic.co/t/wildcard-query-performance/4348 "2011-05-04T17:10:13Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![frazer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/frazer/32/2752_2.png) [@frazer](https://discuss.elastic.co/u/frazer)\
**Post date:** [May 4, 2011, 5:10pm UTC](https://discuss.elastic.co/t/wildcard-query-performance/4348/1 "2011-05-04T17:10:13Z")

</div>

I have the following query:

{  
"sort":  
[  
"\_score"  
],  
"query":  
{  
"bool":  
{  
"must":  
[  
{  
"term":  
{  
"example\_id":1  
}  
},  
{  
"bool":  
{  
"minimum\_number\_should\_match":1,  
"should":  
[  
{  
"query\_string":  
{  
"query":"12\* OR year\*"  
}  
}

```
                    ]
                }
            }
        ]
    }
},
"fields":[]

```

}  
'

It performs quite badly, it takes around 6.5 seconds, the index size  
is around 2.5 million documents.

If I remove the wildcard:  
query\_string": {"query":"12 OR year\*"} \<\< 22 ms

If I change the query to wildcard for letters:  
query\_string": {"query":"ax\* OR year\*"} \<\< 98 ms

I understand there would be some performance penalty for wildcard  
searches but I wouldn't expect the number wildcard search to perform  
so badly.  
query\_string": {"query":"12\* OR year\*"} \<\< 6.5 seconds

Could this be a bug?

---

<div class="post-metadata">

**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\
**Post date:** [May 4, 2011, 5:28pm UTC](https://discuss.elastic.co/t/wildcard-query-performance/4348/2 "2011-05-04T17:28:43Z")

</div>

I can't see how this can be a bug, it can possibly perform bad if there are many terms that match.  
On Wednesday, May 4, 2011 at 8:10 PM, frazer wrote:

> I have the following query:
> 
> {  
> "sort":  
> [  
> "\_score"  
> ],  
> "query":  
> {  
> "bool":  
> {  
> "must":  
> [  
> {  
> "term":  
> {  
> "example\_id":1  
> }  
> },  
> {  
> "bool":  
> {  
> "minimum\_number\_should\_match":1,  
> "should":  
> [  
> {  
> "query\_string":  
> {  
> "query":"12\* OR year\*"  
> }  
> }
> 
> ]  
> }  
> }  
> ]  
> }  
> },  
> "fields":  
> }  
> '
> 
> It performs quite badly, it takes around 6.5 seconds, the index size  
> is around 2.5 million documents.
> 
> If I remove the wildcard:  
> query\_string": {"query":"12 OR year\*"} \<\< 22 ms
> 
> If I change the query to wildcard for letters:  
> query\_string": {"query":"ax\* OR year\*"} \<\< 98 ms
> 
> I understand there would be some performance penalty for wildcard  
> searches but I wouldn't expect the number wildcard search to perform  
> so badly.  
> query\_string": {"query":"12\* OR year\*"} \<\< 6.5 seconds
> 
> Could this be a bug?

---

<div class="post-metadata">

**Author:** ![Administrator\_2](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/administrator_2/32/3211_2.png) [@Administrator\_2](https://discuss.elastic.co/u/Administrator_2)\
**Post date:** [May 4, 2011, 5:38pm UTC](https://discuss.elastic.co/t/wildcard-query-performance/4348/3 "2011-05-04T17:38:27Z")

</div>

frazer,

```
Wildcard queries are notorious for being performance hogs; Lucene

```

doesn't know how to break the word down to any unit less than a term. To  
satify a wildcard query, it has to go through all the items and see that the  
pattern exists in each term. For large result sets this causes a tremendous  
amount of processing overhead.

```
To get around this, depending on your wildcard, you can index each

```

letter individually. Let's say you are using my first name in a field  
called name and would want to run the wildcard query where the wildcard is  
at the end. You could do this:

Name: N  
Name: Ni  
Name: Nic  
Name: Nich  
Name: Nicho  
Name: Nichol  
Name: Nichola  
Name: Nicholas

```
Then, you would search on just the term. Note, this would only work

```

where the wildcard is at one of the ends. If you want it in other  
positions, you would have to set different terms up and then perform a term  
query against that.

```
Of course, the tradeoff here is the size of the index, it will

```

increase tremendously, but you'll gain much better performance for these  
types of queries.

```
	- Nick

```

-----Original Message-----  
From: frazer [[mailto:frazer.horn@gmail.com](mailto:frazer.horn@gmail.com)]  
Sent: Wednesday, May 04, 2011 1:10 PM  
To: users  
Subject: Wildcard query performance

I have the following query:

{  
"sort":  
[  
"\_score"  
],  
"query":  
{  
"bool":  
{  
"must":  
[  
{  
"term":  
{  
"example\_id":1  
}  
},  
{  
"bool":  
{  
"minimum\_number\_should\_match":1,  
"should":  
[  
{  
"query\_string":  
{  
"query":"12\* OR year\*"  
}  
}

```
                    ]
                }
            }
        ]
    }
},
"fields":[]

```

}  
'

It performs quite badly, it takes around 6.5 seconds, the index size  
is around 2.5 million documents.

If I remove the wildcard:  
query\_string": {"query":"12 OR year\*"} \<\< 22 ms

If I change the query to wildcard for letters:  
query\_string": {"query":"ax\* OR year\*"} \<\< 98 ms

I understand there would be some performance penalty for wildcard  
searches but I wouldn't expect the number wildcard search to perform  
so badly.  
query\_string": {"query":"12\* OR year\*"} \<\< 6.5 seconds

Could this be a bug?

---

<div class="post-metadata">

**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\
**Post date:** [May 4, 2011, 5:41pm UTC](https://discuss.elastic.co/t/wildcard-query-performance/4348/4 "2011-05-04T17:41:30Z")

</div>

Just to add on that, many times stemming or using ngram (analysis) can also "solve" the problem for most cases. This can be done also using multi field option.  
On Wednesday, May 4, 2011 at 8:38 PM, Administrator wrote:

> frazer,
> 
> Wildcard queries are notorious for being performance hogs; Lucene  
> doesn't know how to break the word down to any unit less than a term. To  
> satify a wildcard query, it has to go through all the items and see that the  
> pattern exists in each term. For large result sets this causes a tremendous  
> amount of processing overhead.
> 
> To get around this, depending on your wildcard, you can index each  
> letter individually. Let's say you are using my first name in a field  
> called name and would want to run the wildcard query where the wildcard is  
> at the end. You could do this:
> 
> Name: N  
> Name: Ni  
> Name: Nic  
> Name: Nich  
> Name: Nicho  
> Name: Nichol  
> Name: Nichola  
> Name: Nicholas
> 
> Then, you would search on just the term. Note, this would only work  
> where the wildcard is at one of the ends. If you want it in other  
> positions, you would have to set different terms up and then perform a term  
> query against that.
> 
> Of course, the tradeoff here is the size of the index, it will  
> increase tremendously, but you'll gain much better performance for these  
> types of queries.
> 
> - Nick
> 
> -----Original Message-----  
> From: frazer [[mailto:frazer.horn@gmail.com](mailto:frazer.horn@gmail.com)]  
> Sent: Wednesday, May 04, 2011 1:10 PM  
> To: users  
> Subject: Wildcard query performance
> 
> I have the following query:
> 
> {  
> "sort":  
> [  
> "\_score"  
> ],  
> "query":  
> {  
> "bool":  
> {  
> "must":  
> [  
> {  
> "term":  
> {  
> "example\_id":1  
> }  
> },  
> {  
> "bool":  
> {  
> "minimum\_number\_should\_match":1,  
> "should":  
> [  
> {  
> "query\_string":  
> {  
> "query":"12\* OR year\*"  
> }  
> }
> 
> ]  
> }  
> }  
> ]  
> }  
> },  
> "fields":  
> }  
> '
> 
> It performs quite badly, it takes around 6.5 seconds, the index size  
> is around 2.5 million documents.
> 
> If I remove the wildcard:  
> query\_string": {"query":"12 OR year\*"} \<\< 22 ms
> 
> If I change the query to wildcard for letters:  
> query\_string": {"query":"ax\* OR year\*"} \<\< 98 ms
> 
> I understand there would be some performance penalty for wildcard  
> searches but I wouldn't expect the number wildcard search to perform  
> so badly.  
> query\_string": {"query":"12\* OR year\*"} \<\< 6.5 seconds
> 
> Could this be a bug?

---

<div class="post-metadata">

**Author:** ![frazer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/frazer/32/2752_2.png) [@frazer](https://discuss.elastic.co/u/frazer)\
**Post date:** [May 4, 2011, 6:01pm UTC](https://discuss.elastic.co/t/wildcard-query-performance/4348/5 "2011-05-04T18:01:32Z")

</div>

Thanks for the responses, I was trying to point out that there is a  
big difference in performance between these 2 wildcard queries

1. query\_string": {"query":"ax\* OR year\*"} \<\< 98 ms
2. query\_string": {"query":"12\* OR year\*"} \<\< 6 seconds

Im surprised by the difference in performance as I wouldn't expect the  
second query to perform much different to the first, hence I wondered  
if it was a bug but maybe im missing something.

Thanks for your time

Frazer

On May 4, 1:41 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:

> Just to add on that, many times stemming or using ngram (analysis) can also "solve" the problem for most cases. This can be done also using multi field option.
> 
> On Wednesday, May 4, 2011 at 8:38 PM, Administrator wrote:
> 
> > frazer,
> 
> > Wildcard queries are notorious for being performance hogs; Lucene  
> > doesn't know how to break the word down to any unit less than a term. To  
> > satify a wildcard query, it has to go through all the items and see that the  
> > pattern exists in each term. For large result sets this causes a tremendous  
> > amount of processing overhead.
> 
> > To get around this, depending on your wildcard, you can index each  
> > letter individually. Let's say you are using my first name in a field  
> > called name and would want to run the wildcard query where the wildcard is  
> > at the end. You could do this:
> 
> > Name: N  
> > Name: Ni  
> > Name: Nic  
> > Name: Nich  
> > Name: Nicho  
> > Name: Nichol  
> > Name: Nichola  
> > Name: Nicholas
> 
> > Then, you would search on just the term. Note, this would only work  
> > where the wildcard is at one of the ends. If you want it in other  
> > positions, you would have to set different terms up and then perform a term  
> > query against that.
> 
> > Of course, the tradeoff here is the size of the index, it will  
> > increase tremendously, but you'll gain much better performance for these  
> > types of queries.
> 
> > - Nick
> 
> > -----Original Message-----  
> > From: frazer [[mailto:frazer.h...@gmail.com](mailto:frazer.h...@gmail.com)]  
> > Sent: Wednesday, May 04, 2011 1:10 PM  
> > To: users  
> > Subject: Wildcard query performance
> 
> > I have the following query:
> 
> > {  
> > "sort":  
> > [  
> > "\_score"  
> > ],  
> > "query":  
> > {  
> > "bool":  
> > {  
> > "must":  
> > [  
> > {  
> > "term":  
> > {  
> > "example\_id":1  
> > }  
> > },  
> > {  
> > "bool":  
> > {  
> > "minimum\_number\_should\_match":1,  
> > "should":  
> > [  
> > {  
> > "query\_string":  
> > {  
> > "query":"12\* OR year\*"  
> > }  
> > }
> 
> > ]  
> > }  
> > }  
> > ]  
> > }  
> > },  
> > "fields":  
> > }  
> > '
> 
> > It performs quite badly, it takes around 6.5 seconds, the index size  
> > is around 2.5 million documents.
> 
> > If I remove the wildcard:  
> > query\_string": {"query":"12 OR year\*"} \<\< 22 ms
> 
> > If I change the query to wildcard for letters:  
> > query\_string": {"query":"ax\* OR year\*"} \<\< 98 ms
> 
> > I understand there would be some performance penalty for wildcard  
> > searches but I wouldn't expect the number wildcard search to perform  
> > so badly.  
> > query\_string": {"query":"12\* OR year\*"} \<\< 6.5 seconds
> 
> > Could this be a bug?

---

<div class="post-metadata">

**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\
**Post date:** [May 4, 2011, 6:07pm UTC](https://discuss.elastic.co/t/wildcard-query-performance/4348/6 "2011-05-04T18:07:04Z")

</div>

There are probably many more terms matching 12\* compared to ax\* (in the \_all field, note, numeric fields are added to it as well).  
On Wednesday, May 4, 2011 at 9:01 PM, frazer wrote:

> Thanks for the responses, I was trying to point out that there is a  
> big difference in performance between these 2 wildcard queries
> 
> 1. query\_string": {"query":"ax\* OR year\*"} \<\< 98 ms
> 2. query\_string": {"query":"12\* OR year\*"} \<\< 6 seconds
> 
> Im surprised by the difference in performance as I wouldn't expect the  
> second query to perform much different to the first, hence I wondered  
> if it was a bug but maybe im missing something.
> 
> Thanks for your time
> 
> Frazer
> 
> On May 4, 1:41 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
> 
> > Just to add on that, many times stemming or using ngram (analysis) can also "solve" the problem for most cases. This can be done also using multi field option.
> > 
> > On Wednesday, May 4, 2011 at 8:38 PM, Administrator wrote:
> > 
> > > frazer,
> > 
> > > Wildcard queries are notorious for being performance hogs; Lucene  
> > > doesn't know how to break the word down to any unit less than a term. To  
> > > satify a wildcard query, it has to go through all the items and see that the  
> > > pattern exists in each term. For large result sets this causes a tremendous  
> > > amount of processing overhead.
> > 
> > > To get around this, depending on your wildcard, you can index each  
> > > letter individually. Let's say you are using my first name in a field  
> > > called name and would want to run the wildcard query where the wildcard is  
> > > at the end. You could do this:
> > 
> > > Name: N  
> > > Name: Ni  
> > > Name: Nic  
> > > Name: Nich  
> > > Name: Nicho  
> > > Name: Nichol  
> > > Name: Nichola  
> > > Name: Nicholas
> > 
> > > Then, you would search on just the term. Note, this would only work  
> > > where the wildcard is at one of the ends. If you want it in other  
> > > positions, you would have to set different terms up and then perform a term  
> > > query against that.
> > 
> > > Of course, the tradeoff here is the size of the index, it will  
> > > increase tremendously, but you'll gain much better performance for these  
> > > types of queries.
> > 
> > > - Nick
> > 
> > > -----Original Message-----  
> > > From: frazer [[mailto:frazer.h...@gmail.com](mailto:frazer.h...@gmail.com)]  
> > > Sent: Wednesday, May 04, 2011 1:10 PM  
> > > To: users  
> > > Subject: Wildcard query performance
> > 
> > > I have the following query:
> > 
> > > {  
> > > "sort":  
> > > [  
> > > "\_score"  
> > > ],  
> > > "query":  
> > > {  
> > > "bool":  
> > > {  
> > > "must":  
> > > [  
> > > {  
> > > "term":  
> > > {  
> > > "example\_id":1  
> > > }  
> > > },  
> > > {  
> > > "bool":  
> > > {  
> > > "minimum\_number\_should\_match":1,  
> > > "should":  
> > > [  
> > > {  
> > > "query\_string":  
> > > {  
> > > "query":"12\* OR year\*"  
> > > }  
> > > }
> > 
> > > ]  
> > > }  
> > > }  
> > > ]  
> > > }  
> > > },  
> > > "fields":  
> > > }  
> > > '
> > 
> > > It performs quite badly, it takes around 6.5 seconds, the index size  
> > > is around 2.5 million documents.
> > 
> > > If I remove the wildcard:  
> > > query\_string": {"query":"12 OR year\*"} \<\< 22 ms
> > 
> > > If I change the query to wildcard for letters:  
> > > query\_string": {"query":"ax\* OR year\*"} \<\< 98 ms
> > 
> > > I understand there would be some performance penalty for wildcard  
> > > searches but I wouldn't expect the number wildcard search to perform  
> > > so badly.  
> > > query\_string": {"query":"12\* OR year\*"} \<\< 6.5 seconds
> > 
> > > Could this be a bug?

---

<div class="post-metadata">

**Author:** ![frazer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/frazer/32/2752_2.png) [@frazer](https://discuss.elastic.co/u/frazer)\
**Post date:** [May 4, 2011, 6:34pm UTC](https://discuss.elastic.co/t/wildcard-query-performance/4348/7 "2011-05-04T18:34:34Z")

</div>

(in the \_all field, note, numeric fields are added to it as well) \<\< I  
wouldn't mind betting thats it, we have quite a few numeric fields

Thanks for your help

On May 4, 2:07 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:

> There are probably many more terms matching 12\* compared to ax\* (in the \_all field, note, numeric fields are added to it as well).
> 
> On Wednesday, May 4, 2011 at 9:01 PM, frazer wrote:
> 
> > Thanks for the responses, I was trying to point out that there is a  
> > big difference in performance between these 2 wildcard queries
> 
> > 1. query\_string": {"query":"ax\* OR year\*"} \<\< 98 ms
> > 2. query\_string": {"query":"12\* OR year\*"} \<\< 6 seconds
> 
> > Im surprised by the difference in performance as I wouldn't expect the  
> > second query to perform much different to the first, hence I wondered  
> > if it was a bug but maybe im missing something.
> 
> > Thanks for your time
> 
> > Frazer
> 
> > On May 4, 1:41 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
> > 
> > > Just to add on that, many times stemming or using ngram (analysis) can also "solve" the problem for most cases. This can be done also using multi field option.
> 
> > > On Wednesday, May 4, 2011 at 8:38 PM, Administrator wrote:
> > > 
> > > > frazer,
> 
> > > > Wildcard queries are notorious for being performance hogs; Lucene  
> > > > doesn't know how to break the word down to any unit less than a term. To  
> > > > satify a wildcard query, it has to go through all the items and see that the  
> > > > pattern exists in each term. For large result sets this causes a tremendous  
> > > > amount of processing overhead.
> 
> > > > To get around this, depending on your wildcard, you can index each  
> > > > letter individually. Let's say you are using my first name in a field  
> > > > called name and would want to run the wildcard query where the wildcard is  
> > > > at the end. You could do this:
> 
> > > > Name: N  
> > > > Name: Ni  
> > > > Name: Nic  
> > > > Name: Nich  
> > > > Name: Nicho  
> > > > Name: Nichol  
> > > > Name: Nichola  
> > > > Name: Nicholas
> 
> > > > Then, you would search on just the term. Note, this would only work  
> > > > where the wildcard is at one of the ends. If you want it in other  
> > > > positions, you would have to set different terms up and then perform a term  
> > > > query against that.
> 
> > > > Of course, the tradeoff here is the size of the index, it will  
> > > > increase tremendously, but you'll gain much better performance for these  
> > > > types of queries.
> 
> > > > - Nick
> 
> > > > -----Original Message-----  
> > > > From: frazer [[mailto:frazer.h...@gmail.com](mailto:frazer.h...@gmail.com)]  
> > > > Sent: Wednesday, May 04, 2011 1:10 PM  
> > > > To: users  
> > > > Subject: Wildcard query performance
> 
> > > > I have the following query:
> 
> > > > {  
> > > > "sort":  
> > > > [  
> > > > "\_score"  
> > > > ],  
> > > > "query":  
> > > > {  
> > > > "bool":  
> > > > {  
> > > > "must":  
> > > > [  
> > > > {  
> > > > "term":  
> > > > {  
> > > > "example\_id":1  
> > > > }  
> > > > },  
> > > > {  
> > > > "bool":  
> > > > {  
> > > > "minimum\_number\_should\_match":1,  
> > > > "should":  
> > > > [  
> > > > {  
> > > > "query\_string":  
> > > > {  
> > > > "query":"12\* OR year\*"  
> > > > }  
> > > > }
> 
> > > > ]  
> > > > }  
> > > > }  
> > > > ]  
> > > > }  
> > > > },  
> > > > "fields":  
> > > > }  
> > > > '
> 
> > > > It performs quite badly, it takes around 6.5 seconds, the index size  
> > > > is around 2.5 million documents.
> 
> > > > If I remove the wildcard:  
> > > > query\_string": {"query":"12 OR year\*"} \<\< 22 ms
> 
> > > > If I change the query to wildcard for letters:  
> > > > query\_string": {"query":"ax\* OR year\*"} \<\< 98 ms
> 
> > > > I understand there would be some performance penalty for wildcard  
> > > > searches but I wouldn't expect the number wildcard search to perform  
> > > > so badly.  
> > > > query\_string": {"query":"12\* OR year\*"} \<\< 6.5 seconds
> 
> > > > Could this be a bug?

---

<div class="post-metadata">

**Author:** ![otisg](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/otisg/32/492_2.png) [@otisg](https://discuss.elastic.co/u/otisg)\
**Post date:** [May 5, 2011, 3:31pm UTC](https://discuss.elastic.co/t/wildcard-query-performance/4348/8 "2011-05-05T15:31:07Z")

</div>

It's worth pointing out that in Lucene 4.\* Wildcard queries are 100x  
faster:

> **[Lucene's FuzzyQuery is 100 times faster in 4.0](https://blog.mikemccandless.com/2011/03/lucenes-fuzzyquery-is-100-times-faster.html)**
>
> There are many exciting improvements in Lucene's eventual 4.0 (trunk) release, but the awesome speedup to FuzzyQuery really stands out, not...

## Otis

Sematext :: [http://sematext.com/](http://sematext.com/) :: Solr - Lucene - Nutch  
Lucene ecosystem search :: [http://search-lucene.com/](http://search-lucene.com/)

On May 4, 1:38 pm, "Administrator" [ad...@sf4answers.com](mailto:ad...@sf4answers.com) wrote:

> frazer,
> 
> ```
> Wildcard queries are notorious for being performance hogs; Lucene
> 
> ```
> 
> doesn't know how to break the word down to any unit less than a term. To  
> satify a wildcard query, it has to go through all the items and see that the  
> pattern exists in each term. For large result sets this causes a tremendous  
> amount of processing overhead.
> 
> ```
> To get around this, depending on your wildcard, you can index each
> 
> ```
> 
> letter individually. Let's say you are using my first name in a field  
> called name and would want to run the wildcard query where the wildcard is  
> at the end. You could do this:
> 
> Name: N  
> Name: Ni  
> Name: Nic  
> Name: Nich  
> Name: Nicho  
> Name: Nichol  
> Name: Nichola  
> Name: Nicholas
> 
> ```
> Then, you would search on just the term. Note, this would only work
> 
> ```
> 
> where the wildcard is at one of the ends. If you want it in other  
> positions, you would have to set different terms up and then perform a term  
> query against that.
> 
> ```
> Of course, the tradeoff here is the size of the index, it will
> 
> ```
> 
> increase tremendously, but you'll gain much better performance for these  
> types of queries.
> 
> ```
> - Nick
> 
> ```
> 
> -----Original Message-----  
> From: frazer [[mailto:frazer.h...@gmail.com](mailto:frazer.h...@gmail.com)]  
> Sent: Wednesday, May 04, 2011 1:10 PM  
> To: users  
> Subject: Wildcard query performance
> 
> I have the following query:
> 
> {  
> "sort":  
> [  
> "\_score"  
> ],  
> "query":  
> {  
> "bool":  
> {  
> "must":  
> [  
> {  
> "term":  
> {  
> "example\_id":1  
> }  
> },  
> {  
> "bool":  
> {  
> "minimum\_number\_should\_match":1,  
> "should":  
> [  
> {  
> "query\_string":  
> {  
> "query":"12\* OR year\*"  
> }  
> }
> 
> ```
> ]
> }
> }
> ]
> }
> },
> "fields":[]
> 
> ```
> 
> }  
> '
> 
> It performs quite badly, it takes around 6.5 seconds, the index size  
> is around 2.5 million documents.
> 
> If I remove the wildcard:  
> query\_string": {"query":"12 OR year\*"} \<\< 22 ms
> 
> If I change the query to wildcard for letters:  
> query\_string": {"query":"ax\* OR year\*"} \<\< 98 ms
> 
> I understand there would be some performance penalty for wildcard  
> searches but I wouldn't expect the number wildcard search to perform  
> so badly.  
> query\_string": {"query":"12\* OR year\*"} \<\< 6.5 seconds
> 
> Could this be a bug?

---

<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:** [July 6, 2017, 4:06am UTC](https://discuss.elastic.co/t/wildcard-query-performance/4348/9 "2017-07-06T04:06:52Z")

</div>