# Index with additional field taking less space than the same index without it **URL:** \ **Category:** Elasticsearch\ **Created:** [June 19, 2020, 2:26pm UTC](https://discuss.elastic.co/t/index-with-additional-field-taking-less-space-than-the-same-index-without-it/237815 "2020-06-19T14:26:43Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![jnioche](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jnioche/32/13090_2.png) [@jnioche](https://discuss.elastic.co/u/jnioche)\ **Post date:** [June 19, 2020, 2:26pm UTC](https://discuss.elastic.co/t/index-with-additional-field-taking-less-space-than-the-same-index-without-it/237815/1 "2020-06-19T14:26:43Z")
Hi, We have been using a field in a similar way to what the old **\_all** field used to do. We have a bunch of _copy\_to_ from most of our other fields to copy to that field. I have been trying to measure the impact on disk space of removing that field, the idea being that we'll use _simple\_query\_string_ on all the original field instead of just querying the catch-all one. Our index contains 3 billions large documents and space is an issue. I generated 2 indices containing identical data with the copy\_to and without it, the rest of the mapping and configuration is identical. I expected the version of the index without the catch-all field to take less space on disk but amazingly the _store.size\_in\_bytes_ stats reported by Kibana indicate that the index **with** the catch all field takes 33% less space. This is completely unexpected and I can't find an explanation for it. How could not having an additional large field result in a bigger index size? I can't check the stats from Kibana against the actual size on disk as it is spread over many many shards. Any idea? ---
**Author:** ![Vinayak\_Sapre](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vinayak_sapre/32/45939_2.png) [@Vinayak\_Sapre](https://discuss.elastic.co/u/Vinayak_Sapre)\ **Post date:** [June 19, 2020, 4:07pm UTC](https://discuss.elastic.co/t/index-with-additional-field-taking-less-space-than-the-same-index-without-it/237815/2 "2020-06-19T16:07:20Z")
@jnioche Have you forcemeged before comparing sizes? I am assuming both indices are test indices. If you haven't, then force merged by running `POST /index1,index2/_forcemerge?max_num_segments=1` then compare sizes. ---
**Author:** ![jnioche](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jnioche/32/13090_2.png) [@jnioche](https://discuss.elastic.co/u/jnioche)\ **Post date:** [June 22, 2020, 1:29pm UTC](https://discuss.elastic.co/t/index-with-additional-field-taking-less-space-than-the-same-index-without-it/237815/3 "2020-06-22T13:29:18Z")
Yes, I did forcemerge to get a fair comparison. ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [June 23, 2020, 4:38am UTC](https://discuss.elastic.co/t/index-with-additional-field-taking-less-space-than-the-same-index-without-it/237815/4 "2020-06-23T04:38:49Z")
If the mappings apart from this field is identical, have you also verified that the index settings are comparable? One thing that does not show up in the mappings but can have a significant impact on index size is the best\_compression codec. ---
**Author:** ![jnioche](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jnioche/32/13090_2.png) [@jnioche](https://discuss.elastic.co/u/jnioche)\ **Post date:** [June 23, 2020, 7:20am UTC](https://discuss.elastic.co/t/index-with-additional-field-taking-less-space-than-the-same-index-without-it/237815/5 "2020-06-23T07:20:04Z")
The index settings were identical - both used best\_compression and had the same number of shards. I am really puzzled. ---
**Author:** ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)\ **Post date:** [June 23, 2020, 7:54am UTC](https://discuss.elastic.co/t/index-with-additional-field-taking-less-space-than-the-same-index-without-it/237815/6 "2020-06-23T07:54:32Z")
Not sure what is going on. Can you please provide the full index stats and mappings? ---
**Author:** ![jnioche](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jnioche/32/13090_2.png) [@jnioche](https://discuss.elastic.co/u/jnioche)\ **Post date:** [June 24, 2020, 8:36am UTC](https://discuss.elastic.co/t/index-with-additional-field-taking-less-space-than-the-same-index-without-it/237815/8 "2020-06-24T08:36:14Z")
I reran the same experiment and arrived at the opposite conclusion. I am pretty sure I had read the stats correctly though. Probably did something wrong somewhere, sorry and thanks for your answers ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 22, 2020, 8:36am UTC](https://discuss.elastic.co/t/index-with-additional-field-taking-less-space-than-the-same-index-without-it/237815/9 "2020-07-22T08:36:31Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.