# Integer size vs Long size **URL:** \ **Category:** Elasticsearch\ **Created:** [February 14, 2013, 1:25am UTC](https://discuss.elastic.co/t/integer-size-vs-long-size/10736 "2013-02-14T01:25:21Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![ryanogle](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ryanogle/32/2404_2.png) [@ryanogle](https://discuss.elastic.co/u/ryanogle)\ **Post date:** [February 14, 2013, 1:25am UTC](https://discuss.elastic.co/t/integer-size-vs-long-size/10736/1 "2013-02-14T01:25:21Z")
So I have a test index where I define a field1 as type: long. I then define field2 as type:integer. I index 2 documents, each with array of 1000 numbers that are 9 digits in length. In the first document, the array is put in the field1. In the second document, the array is put in the field2. I then go to \_stats and look at the document sizes. I would have expected the document size of the one with the type:integer to be half the size of the one with type:long as the integer is a 32 bit type, and long is a 64 bit type. But both documents are almost exactly the same size. And from my math (each document is around 9K, and 64bit = 8bytes\*9000 characters = 7.2K), it seems that they are all being indexed as long, 64bit. I double checked the \_mapping, and the fields are definitely set as long & integer respectively. Any idea why the document indexed with field type:integer wouldn't be far less in size than the one with type:long? Thanks. -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![jprante](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jprante/32/44941_2.png) [@jprante](https://discuss.elastic.co/u/jprante)\ **Post date:** [February 14, 2013, 8:45am UTC](https://discuss.elastic.co/t/integer-size-vs-long-size/10736/2 "2013-02-14T08:45:16Z")
Have you disabled \_source and \_all for your test? Note, Lucene is an inverted index, it is not behaving like a bag of documents of primitive data types. In spite there are field types like LongField, IntField, DoubleField, FloatField for numerics, this does not determine the overall size of the index files. To simplify, imagine a list of pointers pointing to longs, and a list of pointers pointing to ints. These posting list elements uses the same memory size, no matter what kind of fields you have in a document. Jörg -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**Author:** ![simonw\_2](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/simonw_2/32/1130_2.png) [@simonw\_2](https://discuss.elastic.co/u/simonw_2)\ **Post date:** [February 16, 2013, 3:08pm UTC](https://discuss.elastic.co/t/integer-size-vs-long-size/10736/3 "2013-02-16T15:08:10Z")
Lucene doesn't know about types under the hood. We index numeric types as prefix coded tries to make range queries efficient. The number of bytes a long / int value takes in the index is depending on the precision\_step that is used. but that is the data in the term index. if you are curious about the stored document size, we only know about String / UTF-8 Bytes so we don't store this in the most efficient way a Database would do in a dedicated column. I don't think you can compare the index size to ensure that the right type is applied, I am afraid! simon On Thursday, February 14, 2013 2:25:21 AM UTC+1, ryano wrote: > So I have a test index where I define a field1 as type: long. I then > define field2 as type:integer. I index 2 documents, each with array of > 1000 numbers that are 9 digits in length. In the first document, the array > is put in the field1. In the second document, the array is put in the > field2. > > I then go to \_stats and look at the document sizes. > > I would have expected the document size of the one with the type:integer > to be half the size of the one with type:long as the integer is a 32 bit > type, and long is a 64 bit type. But both documents are almost exactly the > same size. And from my math (each document is around 9K, and 64bit = > 8bytes\*9000 characters = 7.2K), it seems that they are all being indexed as > long, 64bit. > > I double checked the \_mapping, and the fields are definitely set as long & > integer respectively. Any idea why the document indexed with field > type:integer wouldn't be far less in size than the one with type:long? > > Thanks. -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [elasticsearch+unsubscribe@googlegroups.com](mailto:elasticsearch+unsubscribe@googlegroups.com). For more options, visit [https://groups.google.com/groups/opt\_out](https://groups.google.com/groups/opt_out). ---
**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, 2:51am UTC](https://discuss.elastic.co/t/integer-size-vs-long-size/10736/4 "2017-07-06T02:51:12Z")