# Specific fields cache

**URL:** <https://discuss.elastic.co/t/specific-fields-cache/9196>\
**Category:** Elasticsearch\
**Created:** [September 30, 2012, 8:06am UTC](https://discuss.elastic.co/t/specific-fields-cache/9196 "2012-09-30T08:06:42Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![sxamt](https://avatars.discourse-cdn.com/v4/letter/s/5fc32e/32.png) [@sxamt](https://discuss.elastic.co/u/sxamt)\
**Post date:** [September 30, 2012, 8:06am UTC](https://discuss.elastic.co/t/specific-fields-cache/9196/1 "2012-09-30T08:06:42Z")

</div>

Hi,  
I want to use elastic search the following way:  
On start up I want the Elastic Search to load all "my id fields" (one or  
two small fields per document connecting between Lucene Doc Id and my  
entities). The reason for that is I don't want to get Doc Id as a search  
results and again make elastic search go to the disk to fetch me the "my id  
fields" for documents found. Currently this is the way I work with Lucene  
directly and I am pretty happy about it. Is there a way I can make elastic  
search work the same way, in order to avoid another Lucene Db trip?

Thanks!

Maxim

--

---

<div class="post-metadata">

**Author:** ![Ivan](https://avatars.discourse-cdn.com/v4/letter/i/df788c/32.png) [@Ivan](https://discuss.elastic.co/u/Ivan)\
**Post date:** [October 1, 2012, 5:44pm UTC](https://discuss.elastic.co/t/specific-fields-cache/9196/2 "2012-10-01T17:44:16Z")

</div>

Elasticsearch 0.20.0 will have a warmup API that might help:

> <https://github.com/elastic/elasticsearch/issues/1913>
>
> Index warming allows to run registered search requests to warm up the index befo…re it is available for search. With the near real time aspect of search, cold data (segments) will be warmed up before they become available for search.
> 
> Warmup searches typically include requests that require heavy loading of data, such as faceting or sorting on specific fields.
> 
> The warmup APIs allows to register warmup (search) under specific names, remove them, and get them.
> 
> Index warmup can be disabled by setting \`index.warmer.enabled\` to \`false\`. It is supported as a realtime setting using update settings API. This can be handy when doing initial bulk indexing, disabling pre registered warmers to make indexing faster and less expensive and then enable it.
> \## Put Warmer
> 
> Allows to put a warmup search request on a specific index (or indices), with the body composing of a regular search request. Types can be provided as part of the URI if the search request is designed to be run only against the specific types.
> 
> Here is an example that registers a warmup called \`warmer\_1\` against index \`test\` (can be alias or several indices), for a search request that runs against all types:
> 
> \`\`\`
> curl -XPUT localhost:9200/test/\_warmer/warmer\_1 -d '{
> "query" : {
> "match\_all" : {}
> },
> "facets" : {
> "facet\_1" : {
> "terms" : {
> "field" : "field"
> }
> } 
> }
> }'
> \`\`\`
> 
> And an example that registers a warmup against specific types:
> 
> \`\`\`
> curl -XPUT localhost:9200/test/type1/\_warmer/warmer\_1 -d '{
> "query" : {
> "match\_all" : {}
> },
> "facets" : {
> "facet\_1" : {
> "terms" : {
> "field" : "field"
> }
> } 
> }
> }'
> \`\`\`
> \## Delete Warmer
> 
> Removing a warmer can be done against an index (or alias / indices) based on its name. The provided name can be a simple wildcard expression or omitted to remove all warmers. Some samples:
> 
> \`\`\`
> \# delete warmer named warmer\_1 on test index
> curl -XDELETE localhost:9200/test/\_warmer/warmer\_1 
> 
> \# delete all warmers that start with warm on test index
> curl -XDELETE localhost:9200/test/\_warmer/warm\* 
> 
> \# delete all warmers for test index
> curl -XDELETE localhost:9200/test/\_warmer/
> \`\`\`
> \## GETting Warmer
> 
> Getting a warmer for specific index (or alias, or several indices) based on its name. The provided name can be a simple wildcard expression or omitted to get all warmers. Some examples: 
> 
> \`\`\`
> \# get warmer named warmer\_1 on test index
> curl -XGET localhost:9200/test/\_warmer/warmer\_1 
> 
> \# get all warmers that start with warm on test index
> curl -XGET localhost:9200/test/\_warmer/warm\* 
> 
> \# get all warmers for test index
> curl -XGET localhost:9200/test/\_warmer/
> \`\`\`

The issue does not go into much detail besides that it works with new  
segments, but I am assuming it will populate the field caches as well.

If you have source enabled, Elasticsearch should retrieve the entire  
resulting document in one call instead of a separate call for each field.  
Not sure if source is retrieve during search however or if is still another  
Lucene DB trip.

Cheers,

Ivan

On Sun, Sep 30, 2012 at 1:06 AM, Maxim Terletsky [sxamt33@gmail.com](mailto:sxamt33@gmail.com) wrote:

> Hi,  
> I want to use Elasticsearch the following way:  
> On start up I want the Elastic Search to load all "my id fields" (one or  
> two small fields per document connecting between Lucene Doc Id and my  
> entities). The reason for that is I don't want to get Doc Id as a search  
> results and again make Elasticsearch go to the disk to fetch me the "my id  
> fields" for documents found. Currently this is the way I work with Lucene  
> directly and I am pretty happy about it. Is there a way I can make elastic  
> search work the same way, in order to avoid another Lucene Db trip?
> 
> Thanks!
> 
> Maxim
> 
> --

--

---

<div class="post-metadata">

**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, 3:10am UTC](https://discuss.elastic.co/t/specific-fields-cache/9196/3 "2017-07-06T03:10:37Z")

</div>


