# Index/Mapping design considerations when having low cardinality fields **URL:** \ **Category:** Elasticsearch\ **Created:** [April 24, 2016, 9:52pm UTC](https://discuss.elastic.co/t/index-mapping-design-considerations-when-having-low-cardinality-fields/48268 "2016-04-24T21:52:20Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Doron\_B](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/doron_b/32/46835_2.png) [@Doron\_B](https://discuss.elastic.co/u/Doron_B)\ **Post date:** [April 24, 2016, 9:52pm UTC](https://discuss.elastic.co/t/index-mapping-design-considerations-when-having-low-cardinality-fields/48268/1 "2016-04-24T21:52:20Z")
All of my documents holds a 'severity' field with only 4 possible values: LOW, MED, HIGH, CRITICAL The document have much more fields such as timestamp, IP, port, message The opearions that I perform on 'severity' are: 1. Count by 'severity' aggregate by last: day, week, month 2. Get all events with 'severiry'== aggregate by last: day, week, month Is there any sense in dropping the field and having an index per 'severity'? As far as I can tell, this approach: - Will not have improved query performance. After all, I still need to traverse all shards over 4 'severity'indices - Indexing should be faster? Not sure. I think there should be no performance gain - Reverse Index memory footprint should decrease as I will have 1 less, very common, term in my reverse index Marking 'severity' as stop term seems problematic due to the term usage in queries. Since the severity have low cardinality, do I need to take particular considerations when designing my index or mappings? ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 5, 2017, 10:56pm UTC](https://discuss.elastic.co/t/index-mapping-design-considerations-when-having-low-cardinality-fields/48268/2 "2017-07-05T22:56:37Z")