# \[just pushed\] \_all field **URL:** \ **Category:** Elasticsearch\ **Created:** [March 16, 2010, 9:11pm UTC](https://discuss.elastic.co/t/just-pushed--all-field/2848 "2010-03-16T21:11:59Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [March 16, 2010, 9:11pm UTC](https://discuss.elastic.co/t/just-pushed--all-field/2848/1 "2010-03-16T21:11:59Z")
Just pushed support for \_all field. It is documented here: [http://github.com/elasticsearch/elasticsearch/issues/issue/63](http://github.com/elasticsearch/elasticsearch/issues/issue/63). The all field is basically a field that includes one or more document fields, allowing, for example, to simply search on all the document content easily with a queryString query. One can easily disable it, or pick and choose which fields end up in the \_all field. But, there are no free bunnies in software, and enabled \_all means more CPU cycles when indexing, and larger index (but hey, were distributed right? Just Add Machines(tm) ). I believe all is a very important, especially when talking about rich documents, and not simple ones with "title" and "content". The decision currently is to enable \_all by default, and have all the fields included in \_all by default as well. This means that the initial user experience would be very good in terms of usability. But, in terms of performance when indexing, it will be slower (how much slower? really depends on the document and such). What do you think? Does this default make sense? -shay.banon ---
**Author:** ![egaumer](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/egaumer/32/2365_2.png) [@egaumer](https://discuss.elastic.co/u/egaumer)\ **Post date:** [March 17, 2010, 12:02am UTC](https://discuss.elastic.co/t/just-pushed--all-field/2848/2 "2010-03-17T00:02:09Z")
On Mar 16, 5:11 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote: > Just pushed support for \_all field. It is documented here:[\_all field · Issue #63 · elastic/elasticsearch · GitHub](http://github.com/elasticsearch/elasticsearch/issues/issue/63). The all field > is basically a field that includes one or more document fields, allowing, > for example, to simply search on all the document content easily with a > queryString query. One can easily disable it, or pick and choose which > fields end up in the \_all field. > > But, there are no free bunnies in software, and enabled \_all means more CPU > cycles when indexing, and larger index (but hey, were distributed right? > Just Add Machines(tm) ). I believe all is a very important, especially when > talking about rich documents, and not simple ones with "title" and > "content". > > The decision currently is to enable \_all by default, and have all the fields > included in \_all by default as well. This means that the initial user > experience would be very good in terms of usability. But, in terms of > performance when indexing, it will be slower (how much slower? really > depends on the document and such). What do you think? Does this default > make sense? Hey Shay, I think the default setting here is inline with the Elasticsearch mentality of "it just works". If you're a savvy user then the ability to disable this feature is great but novice users should be able to fire up an instance and get the search they'd expect from a Google like experience. With that said, I've been working in this space for about 6 years for Fortune Global 500 companies (mainly with commercial search vendors but also some Lucene work). Every commercial search vendor provides some sort of composite field and I completely agree that this is a must have feature in Elasticsearch. The ability to select which fields belong to the composite is equally important but including "all" by default seems reasonable. I absolutely love the work you've put into Elasticsearch and once I get some time to really investigate the architecture, I plan on providing some help. I think too many folks are thinking about the "big data" problem in terms of storage and forgetting about inherent searchability. These data storage systems need an embedded search layer similar to what's been done with TerraStore. Awesome work and great vision. Regards, -Eric ---
**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, 4:25am UTC](https://discuss.elastic.co/t/just-pushed--all-field/2848/3 "2017-07-06T04:25:17Z")