# Illegal\_argument\_exception Text Fields are not Optmised

**URL:** <https://discuss.elastic.co/t/illegal-argument-exception-text-fields-are-not-optmised/375386>\
**Category:** Elasticsearch\
**Created:** [March 4, 2025, 5:01pm UTC](https://discuss.elastic.co/t/illegal-argument-exception-text-fields-are-not-optmised/375386 "2025-03-04T17:01:56Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![user-27022024](https://avatars.discourse-cdn.com/v4/letter/u/ce7236/32.png) [@user-27022024](https://discuss.elastic.co/u/user-27022024)\
**Post date:** [March 4, 2025, 5:01pm UTC](https://discuss.elastic.co/t/illegal-argument-exception-text-fields-are-not-optmised/375386/1 "2025-03-04T17:01:56Z")

</div>

I have started getting this error when trying to run an average and median on a what certainly used to be mapped as a number.

`Type:` illegal\_argument\_exception  
`Reason:` Text fields are not optimised for operations that require per-document field data like aggregations and sorting, so these operations are disabled by default. Please use a keyword field instead. Alternatively, set fielddata=true on [duration] in order to load field data by uninverting the inverted index. Note that this can use significant memory.

Under `Stack Management` -\> `Index Patterns` it shows as a number

 ![Screenshot 2025-03-04 at 16.57.42](https://us1.discourse-cdn.com/elastic/original/3X/f/b/fb7ed9ca3d313abdb712089bce098fb3555360c8.png)

This is what I have in the Visualize settings

 ![Screenshot 2025-03-04 at 16.59.17](https://us1.discourse-cdn.com/elastic/original/3X/0/e/0e764cc976cf5fc3e066ab61818726f518b8120c.png)

To me this doesn't make sense as it should be mapped to a number?

Edited to add:

Looking at GET /index\_name/\_mappings

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

```

I'm confused as to why it's mapped to a text, but showing as number in the index management?

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [March 4, 2025, 6:57pm UTC](https://discuss.elastic.co/t/illegal-argument-exception-text-fields-are-not-optmised/375386/2 "2025-03-04T18:57:49Z")

</div>

Guessing - As I've seen this, and in our case it was just "luck" that sometimes the first doc for some indices that got indexed didn't have a number for the specific field. Our field was httpCode, and most (vast majority) of the docs ingested had 200, 301, 404, etc. But some had "404 Not Found" or similar. If they happen to be the first, then dynamic field mapping means you get effectively what you saw. Even if the field is "", i.e. no value, it probably defaults to text field.

If my hunch is correct, you cant really fix it without re-indexing. But you can set the mapping in advance of index creation, lots of ways to do this.

You can also check that field mapping for all the indices where it might apply, see how many have the right/wrong mapping.

Oh, and the index-patterns mappings can mislead here as those are not always auto-refreshed.

---

<div class="post-metadata">

**Author:** ![user-27022024](https://avatars.discourse-cdn.com/v4/letter/u/ce7236/32.png) [@user-27022024](https://discuss.elastic.co/u/user-27022024)\
**Post date:** [March 5, 2025, 4:40pm UTC](https://discuss.elastic.co/t/illegal-argument-exception-text-fields-are-not-optmised/375386/3 "2025-03-05T16:40:25Z")

</div>

Thank you for the help - that looks like it's exactly what happened.

How safe is re-indexing? Each index is approximately 30GB - could this cause performance issues?

I ran the re-index with two much smaller indexes and noticed there is very slight difference in sizes

```auto
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
green open logs-small-index-old kQYj-tUWRtyGGsOnL-SKZg 2 1 112467 0 95.2mb 48.2mb
green open logs-small-index-new 5OqsiNwbRu2Mj2yIM3MKhA 2 1 97000 0 96.1mb 47.4mb

```

Is that potentially showing data loss?