# Suggestion for wildcard field type **URL:** \ **Category:** Elasticsearch\ **Created:** [August 5, 2021, 3:51pm UTC](https://discuss.elastic.co/t/suggestion-for-wildcard-field-type/280553 "2021-08-05T15:51:49Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![willemdh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/willemdh/32/16922_2.png) [@willemdh](https://discuss.elastic.co/u/willemdh)\ **Post date:** [August 5, 2021, 3:51pm UTC](https://discuss.elastic.co/t/suggestion-for-wildcard-field-type/280553/1 "2021-08-05T15:51:49Z")
Hello, We need to do a lot of (front) wildcard queries on certain fields. One such field is `url.original`. Currently this is mapped in ECS as keyword. I'm wondering if this could be changed to wildcard field type? For example we need to exclude all firewall logs where url.original ends with `url.original: *.cedexis-test.com/`. I've never used the wildcard field type, but would it be better if we update the mapping to wildcard in such a case to increase performance? > **[Keyword type family | Elasticsearch Guide \[master\] | Elastic](https://www.elastic.co/guide/en/elasticsearch/reference/master/keyword.html#wildcard-field-type)** Willem ---
**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:** [August 5, 2021, 4:11pm UTC](https://discuss.elastic.co/t/suggestion-for-wildcard-field-type/280553/2 "2021-08-05T16:11:23Z")
Roughly speaking leading infix queries (leading wildcard or ._foo._ regexes) have costs as follows: 1. `keyword` fields are linear with the number of unique terms 2. `wildcard` fields are linear with the number of docs that use a term So if your URLs e.g. the site home page appear in many docs these are likely to be slow to match. The flowchart at the end of [this blog](https://www.elastic.co/blog/find-strings-within-strings-faster-with-the-new-elasticsearch-wildcard-field) has a good decision chart. ---
**Author:** ![willemdh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/willemdh/32/16922_2.png) [@willemdh](https://discuss.elastic.co/u/willemdh)\ **Post date:** [August 5, 2021, 4:35pm UTC](https://discuss.elastic.co/t/suggestion-for-wildcard-field-type/280553/3 "2021-08-05T16:35:28Z")
Thanks for the link and the flowchart suggestion, that helps! Just wondering ![image](https://us1.discourse-cdn.com/elastic/original/3X/b/6/b60e92abe1cbd7f2201b145eb1be3ece8f34ec56.png) Does the above unique values mean total unique values for url.orginal or total possible unique values for all possible results when using `*.cedexis-test.com/` I think there are around 1000 unique `*.cedexis-test.com/` in my data, so in that case a keyword would be my best option. But I have 100K+ unique url.original values so than a wildcard would be the best option. ---
**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:** [August 5, 2021, 4:44pm UTC](https://discuss.elastic.co/t/suggestion-for-wildcard-field-type/280553/4 "2021-08-05T16:44:16Z")
> total unique values for url.orginal or total possible unique values for all possible results when using `*.cedexis-test.com/` The former. The thing about prefix/infix queries and keyword fields is the index is of limited use to you. Unlike an exact-match query or leading wildcard, the alphabetic sorting of the list of unique terms can't be used to quickly seek to the relevant part - infix/prefix queries have to scan the full list of all unique terms. With URLs I imagine while there's a lot of unique values they're not evenly divided. So quite "Zipfy" e.g. a handful of URLs account for 90% of all mentions. These very popular URLs will be slow to query with `wildcard` field because it has to verify _each use_ of a term in a doc whereas `keyword` fields need only find the term in the index and be certain all docs listed with that term genuinely do have that term. Benchmarking is the only way to know for sure which is the best approach as so much depends on your data. ---
**Author:** ![willemdh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/willemdh/32/16922_2.png) [@willemdh](https://discuss.elastic.co/u/willemdh)\ **Post date:** [August 5, 2021, 5:00pm UTC](https://discuss.elastic.co/t/suggestion-for-wildcard-field-type/280553/5 "2021-08-05T17:00:09Z")
Thanks @Mark_Harwood I think I'll duplicate the field.original field to another field, eg url.originalwildcard and test both. ---
**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:** [August 5, 2021, 6:14pm UTC](https://discuss.elastic.co/t/suggestion-for-wildcard-field-type/280553/6 "2021-08-05T18:14:22Z")
I'd be interested to hear about your results if you're able to share ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [September 2, 2021, 6:14pm UTC](https://discuss.elastic.co/t/suggestion-for-wildcard-field-type/280553/7 "2021-09-02T18:14:33Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.