# Breaking Change: \_id is not longer indexed
**URL:** https://discuss.elastic.co/t/breaking-change--id-is-not-longer-indexed/4261
**Category:** Elasticsearch
**Created:** [April 19, 2011, 11:54pm UTC](https://discuss.elastic.co/t/breaking-change--id-is-not-longer-indexed/4261 "2011-04-19T23:54:18Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@kimchy](https://discuss.elastic.co/u/kimchy)
#### Post date: [April 19, 2011, 11:54pm UTC](https://discuss.elastic.co/t/breaking-change--id-is-not-longer-indexed/4261/1 "2011-04-19T23:54:18Z")
Heya,
In order to improve memory usage per shard, the \_id field is not longer indexed by default. Note, no capability is lost except for the ability to use search queries using the \_id field. For that, a new ids query / filter was introduced which does not require the \_id field to be indexed (and is actually faster). There is a setting to bring it back if needed.
Issue: [https://github.com/elasticsearch/elasticsearch/issues/868](https://github.com/elasticsearch/elasticsearch/issues/868).
Ids Query/Filter: [https://github.com/elasticsearch/elasticsearch/issues/865](https://github.com/elasticsearch/elasticsearch/issues/865).
As a side note, the \_type mapping can also be set to index : no, with almost all functionality retained (with a bit slower type filtering) and a new type filter, though this does not improve memory consumption by any noticeable measure.
-shay.banon
---
### Author:  [@Sebastian\_Gavarini](https://discuss.elastic.co/u/Sebastian_Gavarini)
#### Post date: [April 20, 2011, 2:08am UTC](https://discuss.elastic.co/t/breaking-change--id-is-not-longer-indexed/4261/2 "2011-04-20T02:08:30Z")
Hi Shay,
I have seen there is also an indexed field in Lucene's indices called "uid",
concatenating "type#id", which is taking a lot of space because the ids are
already unique. Is this still going to be created with this change?
Thanks,
Sebastian.
On Tue, Apr 19, 2011 at 8:54 PM, Shay Banon [shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com)wrote:
> Heya,
>
> In order to improve memory usage per shard, the \_id field is not longer
> indexed by default. Note, no capability is lost except for the ability to
> use search queries using the \_id field. For that, a new ids query / filter
> was introduced which does not require the \_id field to be indexed (and is
> actually faster). There is a setting to bring it back if needed.
>
> Issue: [Mapping: By default, don't index \_id · Issue #868 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/868).
> Ids Query/Filter:
> [Query DSL: Add ids query and filter to fetch docs by ids (do not require \_id field to be indexed) · Issue #865 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/865).
>
> As a side note, the \_type mapping can also be set to index : no, with
> almost all functionality retained (with a bit slower type filtering) and a
> new type filter, though this does not improve memory consumption by any
> noticeable measure.
>
> -shay.banon
---
### Author:  [@kimchy](https://discuss.elastic.co/u/kimchy)
#### Post date: [April 20, 2011, 9:50am UTC](https://discuss.elastic.co/t/breaking-change--id-is-not-longer-indexed/4261/3 "2011-04-20T09:50:52Z")
Ids are not required to be unique across types. The uid will always be created, the \_id will not. You need to have a way to identify the doc.
On Wednesday, April 20, 2011 at 5:08 AM, Sebastian Gavarini wrote:
> Hi Shay,
>
> I have seen there is also an indexed field in Lucene's indices called "uid", concatenating "type#id", which is taking a lot of space because the ids are already unique. Is this still going to be created with this change?
>
> Thanks,
> Sebastian.
>
> On Tue, Apr 19, 2011 at 8:54 PM, Shay Banon [shay.banon@elasticsearch.com](mailto:shay.banon@elasticsearch.com) wrote:
>
> > Heya,
> >
> > In order to improve memory usage per shard, the \_id field is not longer indexed by default. Note, no capability is lost except for the ability to use search queries using the \_id field. For that, a new ids query / filter was introduced which does not require the \_id field to be indexed (and is actually faster). There is a setting to bring it back if needed.
> >
> > Issue: [Mapping: By default, don't index \_id · Issue #868 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/868).
> > Ids Query/Filter: [Query DSL: Add ids query and filter to fetch docs by ids (do not require \_id field to be indexed) · Issue #865 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/865).
> >
> > As a side note, the \_type mapping can also be set to index : no, with almost all functionality retained (with a bit slower type filtering) and a new type filter, though this does not improve memory consumption by any noticeable measure.
> >
> > -shay.banon
---
### Author:  [@Grant\_Rodgers](https://discuss.elastic.co/u/Grant_Rodgers)
#### Post date: [April 23, 2011, 9:58pm UTC](https://discuss.elastic.co/t/breaking-change--id-is-not-longer-indexed/4261/4 "2011-04-23T21:58:59Z")
Does this remove the ability to order by \_id?
On Apr 19, 4:54 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
> Heya,
>
> In order to improve memory usage per shard, the \_id field is not longer indexed by default. Note, no capability is lost except for the ability to use search queries using the \_id field. For that, a new ids query / filter was introduced which does not require the \_id field to be indexed (and is actually faster). There is a setting to bring it back if needed.
>
> Issue:[Mapping: By default, don't index \_id · Issue #868 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/868).
> Ids Query/Filter:[Query DSL: Add ids query and filter to fetch docs by ids (do not require \_id field to be indexed) · Issue #865 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/865).
>
> As a side note, the \_type mapping can also be set to index : no, with almost all functionality retained (with a bit slower type filtering) and a new type filter, though this does not improve memory consumption by any noticeable measure.
>
> -shay.banon
---
### Author:  [@kimchy](https://discuss.elastic.co/u/kimchy)
#### Post date: [April 24, 2011, 6:35am UTC](https://discuss.elastic.co/t/breaking-change--id-is-not-longer-indexed/4261/5 "2011-04-24T06:35:35Z")
Yes.
On Sunday, April 24, 2011 at 12:58 AM, Grant Rodgers wrote:
> Does this remove the ability to order by \_id?
>
> On Apr 19, 4:54 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
>
> > Heya,
> >
> > In order to improve memory usage per shard, the \_id field is not longer indexed by default. Note, no capability is lost except for the ability to use search queries using the \_id field. For that, a new ids query / filter was introduced which does not require the \_id field to be indexed (and is actually faster). There is a setting to bring it back if needed.
> >
> > Issue:[Mapping: By default, don't index \_id · Issue #868 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/868).
> > Ids Query/Filter:[Query DSL: Add ids query and filter to fetch docs by ids (do not require \_id field to be indexed) · Issue #865 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/865).
> >
> > As a side note, the \_type mapping can also be set to index : no, with almost all functionality retained (with a bit slower type filtering) and a new type filter, though this does not improve memory consumption by any noticeable measure.
> >
> > -shay.banon
---
### Author:  [@kimchy](https://discuss.elastic.co/u/kimchy)
#### Post date: [April 24, 2011, 6:48am UTC](https://discuss.elastic.co/t/breaking-change--id-is-not-longer-indexed/4261/6 "2011-04-24T06:48:03Z")
Though, to add on that, there is a setting to set to make sure it is still indexed when upgrading. And, if starting fresh, you can mark it as indexed. I plan to also add a special sort option for id, that will be less memory heavy.
On Sunday, April 24, 2011 at 9:35 AM, Shay Banon wrote:
> Yes.
> On Sunday, April 24, 2011 at 12:58 AM, Grant Rodgers wrote:
>
> > Does this remove the ability to order by \_id?
> >
> > On Apr 19, 4:54 pm, Shay Banon [shay.ba...@elasticsearch.com](mailto:shay.ba...@elasticsearch.com) wrote:
> >
> > > Heya,
> > >
> > > In order to improve memory usage per shard, the \_id field is not longer indexed by default. Note, no capability is lost except for the ability to use search queries using the \_id field. For that, a new ids query / filter was introduced which does not require the \_id field to be indexed (and is actually faster). There is a setting to bring it back if needed.
> > >
> > > Issue:[Mapping: By default, don't index \_id · Issue #868 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/868).
> > > Ids Query/Filter:[Query DSL: Add ids query and filter to fetch docs by ids (do not require \_id field to be indexed) · Issue #865 · elastic/elasticsearch · GitHub](https://github.com/elasticsearch/elasticsearch/issues/865).
> > >
> > > As a side note, the \_type mapping can also be set to index : no, with almost all functionality retained (with a bit slower type filtering) and a new type filter, though this does not improve memory consumption by any noticeable measure.
> > >
> > > -shay.banon
---
### Author:  [@system](https://discuss.elastic.co/u/system)
#### Post date: [July 6, 2017, 4:07am UTC](https://discuss.elastic.co/t/breaking-change--id-is-not-longer-indexed/4261/7 "2017-07-06T04:07:45Z")