# Efficiency of search vs get

**URL:** <https://discuss.elastic.co/t/efficiency-of-search-vs-get/5389>\
**Category:** Elasticsearch\
**Created:** [September 15, 2011, 7:06pm UTC](https://discuss.elastic.co/t/efficiency-of-search-vs-get/5389 "2011-09-15T19:06:19Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![Steff](https://avatars.discourse-cdn.com/v4/letter/s/e36b37/32.png) [@Steff](https://discuss.elastic.co/u/Steff)\
**Post date:** [September 15, 2011, 7:06pm UTC](https://discuss.elastic.co/t/efficiency-of-search-vs-get/5389/1 "2011-09-15T19:06:19Z")

</div>

curl -X PUT "localhost:9200/mytest/abc/\_mapping" -d '{  
"abc" : {  
"\_routing" : {  
"required" : true  
}  
"properties" : {  
"idx" : {"type" : "string", "index" : "not\_analyzed"},  
"a" : {"type" : "string"},  
"b" : {"type" : "string"},  
"c" : {"type" : "integer"},  
"txt" : {"type" : "string", "null\_value" : "na"}  
}  
}  
}

Lots of abc documents indexed into mytest index - a.o. this  
curl -XPUT  
"localhost:9200/mytest/abc/1234\_5678\_90123?routing=1234\_5678\_90123" -d '{  
"sms" :  
{  
"a" : "1234",  
"b" : "5678",  
"c" : 90123,  
"txt" : "Hello World"  
}  
}

Expect this "get" will be very efficient:  
curl -XGET  
"[http://localhost:9200/mytest/abc/1234\_5678\_90123?routing=1234\_5678\_90123](http://localhost:9200/mytest/abc/1234_5678_90123?routing=1234_5678_90123)"

I have cheated a little in the code above, when I indicate that I can  
make an id consisting of the values of a, b and c. It is only almost  
true - sometimes (but very very seldom) there will be documents with the  
same values for a, b and c. Therefore I cannot make id's like this (will  
have to make a\_b\_c\_X id's og just GUID id's instead), and therefore I  
cannot "find" the document(s) using the "get" above.

Question: If I know that there will never be more than a few documents  
with concrete values for a, b and c, can I create a "search" finding  
those documents, a search that is just (or almost) as efficient (with  
respect to searchtime and resources used) as the "get" above? Note that  
I am using routing so I should at least be able to hit the right shard  
in such a search.

In a RDMS I would make an combined index of a, b and c and use the query  
"select \* from abc where a="1234" and b="5678" and c=90123" (the  
"search") instead of "select \* from abc where id="1234\_5678\_90123"" (the  
"get"), and that would be just as efficient (if the RDMS uses the  
combined index, or else I will force it by hinting).

Thanks!

Regards, Per Steffensen

---

<div class="post-metadata">

**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:** [September 16, 2011, 10:05pm UTC](https://discuss.elastic.co/t/efficiency-of-search-vs-get/5389/2 "2011-09-16T22:05:27Z")

</div>

Get is as fast as you can go to retrieve a single document, search against a  
single field (term query) that uses routing to direct the search request to  
a single shard will be almost as fast, but not the same. I don't have actual  
numbers to say how slower it will be.

Regarding a combined index, there is no option to do that in elasticsearch.  
You can do a boolean query, with several must clauses including term query  
against a, b, and c. This will be slower (since now you are not searching on  
a single field, but 3).

On the other hand, the \_routing field is automatically indexed (not  
analyzed). So, based on the same below, you can simply do a term query  
against \_routing field with the routing value.

Of course, you might get several documents with the search request, but I  
think you factored that in (a\_b\_c\_1, and a\_b\_c\_2).

On Thu, Sep 15, 2011 at 10:06 PM, Per Steffensen [steff@designware.dk](mailto:steff@designware.dk)wrote:

> curl -X PUT "localhost:9200/mytest/abc/\_\*\*mapping" -d '{  
> "abc" : {  
> "\_routing" : {  
> "required" : true  
> }  
> "properties" : {  
> "idx" : {"type" : "string", "index" : "not\_analyzed"},  
> "a" : {"type" : "string"},  
> "b" : {"type" : "string"},  
> "c" : {"type" : "integer"},  
> "txt" : {"type" : "string", "null\_value" : "na"}  
> }  
> }  
> }
> 
> Lots of abc documents indexed into mytest index - a.o. this  
> curl -XPUT "localhost:9200/mytest/abc/\*\*1234\_5678\_90123?routing=1234\_\*\*5678\_90123"  
> -d '{  
> "sms" :  
> {  
> "a" : "1234",  
> "b" : "5678",  
> "c" : 90123,  
> "txt" : "Hello World"  
> }  
> }
> 
> Expect this "get" will be very efficient:  
> curl -XGET "[http://localhost:9200/mytest/\*\*abc/1234\_5678\_90123?routing=](http://localhost:9200/mytest/**abc/1234_5678_90123?routing=)\*\*  
> 1234\_5678\_90123[http://localhost:9200/mytest/abc/1234\_5678\_90123?routing=1234\_5678\_90123](http://localhost:9200/mytest/abc/1234_5678_90123?routing=1234_5678_90123)  
> "
> 
> I have cheated a little in the code above, when I indicate that I can make  
> an id consisting of the values of a, b and c. It is only almost true -  
> sometimes (but very very seldom) there will be documents with the same  
> values for a, b and c. Therefore I cannot make id's like this (will have to  
> make a\_b\_c\_X id's og just GUID id's instead), and therefore I cannot "find"  
> the document(s) using the "get" above.
> 
> Question: If I know that there will never be more than a few documents with  
> concrete values for a, b and c, can I create a "search" finding those  
> documents, a search that is just (or almost) as efficient (with respect to  
> searchtime and resources used) as the "get" above? Note that I am using  
> routing so I should at least be able to hit the right shard in such a  
> search.
> 
> In a RDMS I would make an combined index of a, b and c and use the query  
> "select \* from abc where a="1234" and b="5678" and c=90123" (the "search")  
> instead of "select \* from abc where id="1234\_5678\_90123"" (the "get"), and  
> that would be just as efficient (if the RDMS uses the combined index, or  
> else I will force it by hinting).
> 
> Thanks!
> 
> Regards, Per Steffensen

---

<div class="post-metadata">

**Author:** ![Steff](https://avatars.discourse-cdn.com/v4/letter/s/e36b37/32.png) [@Steff](https://discuss.elastic.co/u/Steff)\
**Post date:** [September 23, 2011, 8:18pm UTC](https://discuss.elastic.co/t/efficiency-of-search-vs-get/5389/3 "2011-09-23T20:18:49Z")

</div>

Shay Banon skrev:

> Get is as fast as you can go to retrieve a single document, search  
> against a single field (term query) that uses routing to direct the  
> search request to a single shard will be almost as fast, but not the  
> same. I don't have actual numbers to say how slower it will be.
> 
> Regarding a combined index, there is no option to do that in  
> elasticsearch. You can do a boolean query, with several must clauses  
> including term query against a, b, and c. This will be slower (since  
> now you are not searching on a single field, but 3).
> 
> On the other hand, the \_routing field is automatically indexed (not  
> analyzed). So, based on the same below, you can simply do a term query  
> against \_routing field with the routing value.  
> Thanks. Will the following code do the trick?

client.prepareSearch(indexName).setRouting(routingStr).setFilter(new  
TermFilterBuilder("\_routing", routingStr)).execute().actionGet();

> Of course, you might get several documents with the search request,  
> but I think you factored that in (a\_b\_c\_1, and a\_b\_c\_2).
> 
> On Thu, Sep 15, 2011 at 10:06 PM, Per Steffensen \<steff@designware.dk  
> [mailto:steff@designware.dk](mailto:steff@designware.dk)\> wrote:
> 
> ```
> curl -X PUT "localhost:9200/mytest/abc/_mapping" -d '{
> "abc" : {
> "_routing" : {
> "required" : true
> }
> "properties" : {
> "idx" : {"type" : "string", "index" : "not_analyzed"},
> "a" : {"type" : "string"},
> "b" : {"type" : "string"},
> "c" : {"type" : "integer"},
> "txt" : {"type" : "string", "null_value" : "na"}
> }
> }
> }
> 
> Lots of abc documents indexed into mytest index - a.o. this
> curl -XPUT
> "localhost:9200/mytest/abc/1234_5678_90123?routing=1234_5678_90123"
> -d '{
> "sms" :
> {
> "a" : "1234",
> "b" : "5678",
> "c" : 90123,
> "txt" : "Hello World"
> }
> }
> 
> Expect this "get" will be very efficient:
> curl -XGET
> "http://localhost:9200/mytest/abc/1234_5678_90123?routing=1234_5678_90123"
> 
> I have cheated a little in the code above, when I indicate that I
> can make an id consisting of the values of a, b and c. It is only
> almost true - sometimes (but very very seldom) there will be
> documents with the same values for a, b and c. Therefore I cannot
> make id's like this (will have to make a_b_c_X id's og just GUID
> id's instead), and therefore I cannot "find" the document(s) using
> the "get" above.
> 
> Question: If I know that there will never be more than a few
> documents with concrete values for a, b and c, can I create a
> "search" finding those documents, a search that is just (or
> almost) as efficient (with respect to searchtime and resources
> used) as the "get" above? Note that I am using routing so I should
> at least be able to hit the right shard in such a search.
> 
> In a RDMS I would make an combined index of a, b and c and use the
> query "select * from abc where a="1234" and b="5678" and c=90123"
> (the "search") instead of "select * from abc where
> id="1234_5678_90123"" (the "get"), and that would be just as
> efficient (if the RDMS uses the combined index, or else I will
> force it by hinting).
> 
> Thanks!
> 
> Regards, Per Steffensen
> 
> ```

---

<div class="post-metadata">

**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:** [September 23, 2011, 11:15pm UTC](https://discuss.elastic.co/t/efficiency-of-search-vs-get/5389/4 "2011-09-23T23:15:43Z")

</div>

Replace setFilter with setQuery(QueryBuilders.termQuery("\_routing",  
routingStr), as the filter is mainly used to filter results fo the query you  
execute (mainly used with faceting).

On Fri, Sep 23, 2011 at 11:18 PM, Per Steffensen [steff@designware.dk](mailto:steff@designware.dk)wrote:

> \*\*  
> Shay Banon skrev:
> 
> Get is as fast as you can go to retrieve a single document, search against  
> a single field (term query) that uses routing to direct the search request  
> to a single shard will be almost as fast, but not the same. I don't have  
> actual numbers to say how slower it will be.
> 
> Regarding a combined index, there is no option to do that in  
> elasticsearch. You can do a boolean query, with several must clauses  
> including term query against a, b, and c. This will be slower (since now you  
> are not searching on a single field, but 3).
> 
> On the other hand, the \_routing field is automatically indexed (not  
> analyzed). So, based on the same below, you can simply do a term query  
> against \_routing field with the routing value.
> 
> Thanks. Will the following code do the trick?
> 
> client.prepareSearch(indexName).setRouting(routingStr).setFilter(new  
> TermFilterBuilder("\_routing", routingStr)).execute().actionGet();
> 
> Of course, you might get several documents with the search request, but I  
> think you factored that in (a\_b\_c\_1, and a\_b\_c\_2).
> 
> On Thu, Sep 15, 2011 at 10:06 PM, Per Steffensen [steff@designware.dk](mailto:steff@designware.dk)wrote:
> 
> > curl -X PUT "localhost:9200/mytest/abc/\_mapping" -d '{  
> > "abc" : {  
> > "\_routing" : {  
> > "required" : true  
> > }  
> > "properties" : {  
> > "idx" : {"type" : "string", "index" : "not\_analyzed"},  
> > "a" : {"type" : "string"},  
> > "b" : {"type" : "string"},  
> > "c" : {"type" : "integer"},  
> > "txt" : {"type" : "string", "null\_value" : "na"}  
> > }  
> > }  
> > }
> > 
> > Lots of abc documents indexed into mytest index - a.o. this  
> > curl -XPUT  
> > "localhost:9200/mytest/abc/1234\_5678\_90123?routing=1234\_5678\_90123" -d '{  
> > "sms" :  
> > {  
> > "a" : "1234",  
> > "b" : "5678",  
> > "c" : 90123,  
> > "txt" : "Hello World"  
> > }  
> > }
> > 
> > Expect this "get" will be very efficient:  
> > curl -XGET "  
> > [http://localhost:9200/mytest/abc/1234\_5678\_90123?routing=1234\_5678\_90123](http://localhost:9200/mytest/abc/1234_5678_90123?routing=1234_5678_90123)"
> > 
> > I have cheated a little in the code above, when I indicate that I can make  
> > an id consisting of the values of a, b and c. It is only almost true -  
> > sometimes (but very very seldom) there will be documents with the same  
> > values for a, b and c. Therefore I cannot make id's like this (will have to  
> > make a\_b\_c\_X id's og just GUID id's instead), and therefore I cannot "find"  
> > the document(s) using the "get" above.
> > 
> > Question: If I know that there will never be more than a few documents  
> > with concrete values for a, b and c, can I create a "search" finding those  
> > documents, a search that is just (or almost) as efficient (with respect to  
> > searchtime and resources used) as the "get" above? Note that I am using  
> > routing so I should at least be able to hit the right shard in such a  
> > search.
> > 
> > In a RDMS I would make an combined index of a, b and c and use the query  
> > "select \* from abc where a="1234" and b="5678" and c=90123" (the "search")  
> > instead of "select \* from abc where id="1234\_5678\_90123"" (the "get"), and  
> > that would be just as efficient (if the RDMS uses the combined index, or  
> > else I will force it by hinting).
> > 
> > Thanks!
> > 
> > Regards, Per Steffensen

---

<div class="post-metadata">

**Author:** ![thale\_jacobs](https://avatars.discourse-cdn.com/v4/letter/t/b19c9b/32.png) [@thale\_jacobs](https://discuss.elastic.co/u/thale_jacobs)\
**Post date:** [July 16, 2014, 5:28pm UTC](https://discuss.elastic.co/t/efficiency-of-search-vs-get/5389/5 "2014-07-16T17:28:37Z")

</div>

From the example:  
client.prepareSearch(indexName).setRouting(routingStr).setQuery(  
QueryBuilders.termQuery("\_routing", routingStr)).execute().actionGet();

For clarification, can someone verify that the routing needs to be  
specified via setRouting(routingStr) as well as  
TermQuery(QueryBuilders.termQuery("\_routing", routingStr)...? I am  
having a difficult time finding documentation on the java client api as it  
pertains to routing. Thanks for the help.

On Friday, September 23, 2011 7:15:43 PM UTC-4, kimchy wrote:

> Replace setFilter with setQuery(QueryBuilders.termQuery("\_routing",  
> routingStr), as the filter is mainly used to filter results fo the query  
> you execute (mainly used with faceting).
> 
> On Fri, Sep 23, 2011 at 11:18 PM, Per Steffensen \<st...@designware.dk  
> \<javascript:\>\> wrote:
> 
> > Shay Banon skrev:
> > 
> > Get is as fast as you can go to retrieve a single document, search  
> > against a single field (term query) that uses routing to direct the search  
> > request to a single shard will be almost as fast, but not the same. I don't  
> > have actual numbers to say how slower it will be.
> > 
> > Regarding a combined index, there is no option to do that in  
> > elasticsearch. You can do a boolean query, with several must clauses  
> > including term query against a, b, and c. This will be slower (since now  
> > you are not searching on a single field, but 3).
> > 
> > On the other hand, the \_routing field is automatically indexed (not  
> > analyzed). So, based on the same below, you can simply do a term query  
> > against \_routing field with the routing value.
> > 
> > Thanks. Will the following code do the trick?
> > 
> > client.prepareSearch(indexName).setRouting(routingStr).setFilter(new  
> > TermFilterBuilder("\_routing", routingStr)).execute().actionGet();
> > 
> > Of course, you might get several documents with the search request, but  
> > I think you factored that in (a\_b\_c\_1, and a\_b\_c\_2).
> > 
> > On Thu, Sep 15, 2011 at 10:06 PM, Per Steffensen \<st...@designware.dk  
> > \<javascript:\>\> wrote:
> > 
> > > curl -X PUT "localhost:9200/mytest/abc/\_mapping" -d '{  
> > > "abc" : {  
> > > "\_routing" : {  
> > > "required" : true  
> > > }  
> > > "properties" : {  
> > > "idx" : {"type" : "string", "index" : "not\_analyzed"},  
> > > "a" : {"type" : "string"},  
> > > "b" : {"type" : "string"},  
> > > "c" : {"type" : "integer"},  
> > > "txt" : {"type" : "string", "null\_value" : "na"}  
> > > }  
> > > }  
> > > }
> > > 
> > > Lots of abc documents indexed into mytest index - a.o. this  
> > > curl -XPUT  
> > > "localhost:9200/mytest/abc/1234\_5678\_90123?routing=1234\_5678\_90123" -d '{  
> > > "sms" :  
> > > {  
> > > "a" : "1234",  
> > > "b" : "5678",  
> > > "c" : 90123,  
> > > "txt" : "Hello World"  
> > > }  
> > > }
> > > 
> > > Expect this "get" will be very efficient:  
> > > curl -XGET "  
> > > [http://localhost:9200/mytest/abc/1234\_5678\_90123?routing=1234\_5678\_90123](http://localhost:9200/mytest/abc/1234_5678_90123?routing=1234_5678_90123)  
> > > "
> > > 
> > > I have cheated a little in the code above, when I indicate that I can  
> > > make an id consisting of the values of a, b and c. It is only almost true -  
> > > sometimes (but very very seldom) there will be documents with the same  
> > > values for a, b and c. Therefore I cannot make id's like this (will have to  
> > > make a\_b\_c\_X id's og just GUID id's instead), and therefore I cannot "find"  
> > > the document(s) using the "get" above.
> > > 
> > > Question: If I know that there will never be more than a few documents  
> > > with concrete values for a, b and c, can I create a "search" finding those  
> > > documents, a search that is just (or almost) as efficient (with respect to  
> > > searchtime and resources used) as the "get" above? Note that I am using  
> > > routing so I should at least be able to hit the right shard in such a  
> > > search.
> > > 
> > > In a RDMS I would make an combined index of a, b and c and use the query  
> > > "select \* from abc where a="1234" and b="5678" and c=90123" (the "search")  
> > > instead of "select \* from abc where id="1234\_5678\_90123"" (the "get"), and  
> > > that would be just as efficient (if the RDMS uses the combined index, or  
> > > else I will force it by hinting).
> > > 
> > > Thanks!
> > > 
> > > Regards, Per Steffensen

--  
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).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/7012fe03-4b32-4a86-8ca2-0cfdeb635760%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/7012fe03-4b32-4a86-8ca2-0cfdeb635760%40googlegroups.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<div class="post-metadata">

**Author:** ![spinscale](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/spinscale/32/25011_2.png) [@spinscale](https://discuss.elastic.co/u/spinscale)\
**Post date:** [July 28, 2014, 12:16pm UTC](https://discuss.elastic.co/t/efficiency-of-search-vs-get/5389/6 "2014-07-28T12:16:16Z")

</div>

Hey,

it is sufficient to set the routing via setRouting in the Java API... in  
case of doubts, you can always check the RestActions in the source and see  
how they do it...

--Alex

On Wed, Jul 16, 2014 at 7:28 PM, thale jacobs [thalejacobs@gmail.com](mailto:thalejacobs@gmail.com) wrote:

> From the example:  
> client.prepareSearch(indexName).setRouting(routingStr).setQuery(  
> QueryBuilders.termQuery("\_routing", routingStr)).execute().actionGet();
> 
> For clarification, can someone verify that the routing needs to be  
> specified via setRouting(routingStr) as well as  
> TermQuery(QueryBuilders.termQuery("\_routing", routingStr)...? I am  
> having a difficult time finding documentation on the java client api as it  
> pertains to routing. Thanks for the help.
> 
> On Friday, September 23, 2011 7:15:43 PM UTC-4, kimchy wrote:
> 
> > Replace setFilter with setQuery(QueryBuilders.termQuery("\_routing",  
> > routingStr), as the filter is mainly used to filter results fo the query  
> > you execute (mainly used with faceting).
> > 
> > On Fri, Sep 23, 2011 at 11:18 PM, Per Steffensen [st...@designware.dk](mailto:st...@designware.dk)  
> > wrote:
> > 
> > > Shay Banon skrev:
> > > 
> > > Get is as fast as you can go to retrieve a single document, search  
> > > against a single field (term query) that uses routing to direct the search  
> > > request to a single shard will be almost as fast, but not the same. I don't  
> > > have actual numbers to say how slower it will be.
> > > 
> > > Regarding a combined index, there is no option to do that in  
> > > elasticsearch. You can do a boolean query, with several must clauses  
> > > including term query against a, b, and c. This will be slower (since now  
> > > you are not searching on a single field, but 3).
> > > 
> > > On the other hand, the \_routing field is automatically indexed (not  
> > > analyzed). So, based on the same below, you can simply do a term query  
> > > against \_routing field with the routing value.
> > > 
> > > Thanks. Will the following code do the trick?
> > > 
> > > client.prepareSearch(indexName).setRouting(routingStr).setFilter(new  
> > > TermFilterBuilder("\_routing", routingStr)).execute().actionGet();
> > > 
> > > Of course, you might get several documents with the search request,  
> > > but I think you factored that in (a\_b\_c\_1, and a\_b\_c\_2).
> > > 
> > > On Thu, Sep 15, 2011 at 10:06 PM, Per Steffensen [st...@designware.dk](mailto:st...@designware.dk)  
> > > wrote:
> > > 
> > > > curl -X PUT "localhost:9200/mytest/abc/\_mapping" -d '{  
> > > > "abc" : {  
> > > > "\_routing" : {  
> > > > "required" : true  
> > > > }  
> > > > "properties" : {  
> > > > "idx" : {"type" : "string", "index" : "not\_analyzed"},  
> > > > "a" : {"type" : "string"},  
> > > > "b" : {"type" : "string"},  
> > > > "c" : {"type" : "integer"},  
> > > > "txt" : {"type" : "string", "null\_value" : "na"}  
> > > > }  
> > > > }  
> > > > }
> > > > 
> > > > Lots of abc documents indexed into mytest index - a.o. this  
> > > > curl -XPUT "localhost:9200/mytest/abc/1234\_5678\_90123?routing=1234\_5678\_90123"  
> > > > -d '{  
> > > > "sms" :  
> > > > {  
> > > > "a" : "1234",  
> > > > "b" : "5678",  
> > > > "c" : 90123,  
> > > > "txt" : "Hello World"  
> > > > }  
> > > > }
> > > > 
> > > > Expect this "get" will be very efficient:  
> > > > curl -XGET "[http://localhost:9200/mytest/abc/1234\_5678\_90123?routing=](http://localhost:9200/mytest/abc/1234_5678_90123?routing=)  
> > > > 1234\_5678\_90123"
> > > > 
> > > > I have cheated a little in the code above, when I indicate that I can  
> > > > make an id consisting of the values of a, b and c. It is only almost true -  
> > > > sometimes (but very very seldom) there will be documents with the same  
> > > > values for a, b and c. Therefore I cannot make id's like this (will have to  
> > > > make a\_b\_c\_X id's og just GUID id's instead), and therefore I cannot "find"  
> > > > the document(s) using the "get" above.
> > > > 
> > > > Question: If I know that there will never be more than a few documents  
> > > > with concrete values for a, b and c, can I create a "search" finding those  
> > > > documents, a search that is just (or almost) as efficient (with respect to  
> > > > searchtime and resources used) as the "get" above? Note that I am using  
> > > > routing so I should at least be able to hit the right shard in such a  
> > > > search.
> > > > 
> > > > In a RDMS I would make an combined index of a, b and c and use the  
> > > > query "select \* from abc where a="1234" and b="5678" and c=90123" (the  
> > > > "search") instead of "select \* from abc where id="1234\_5678\_90123"" (the  
> > > > "get"), and that would be just as efficient (if the RDMS uses the combined  
> > > > index, or else I will force it by hinting).
> > > > 
> > > > Thanks!
> > > > 
> > > > Regards, Per Steffensen
> > 
> > --  
> > 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).  
> > To view this discussion on the web visit  
> > [https://groups.google.com/d/msgid/elasticsearch/7012fe03-4b32-4a86-8ca2-0cfdeb635760%40googlegroups.com](https://groups.google.com/d/msgid/elasticsearch/7012fe03-4b32-4a86-8ca2-0cfdeb635760%40googlegroups.com)  
> > [https://groups.google.com/d/msgid/elasticsearch/7012fe03-4b32-4a86-8ca2-0cfdeb635760%40googlegroups.com?utm\_medium=email&utm\_source=footer](https://groups.google.com/d/msgid/elasticsearch/7012fe03-4b32-4a86-8ca2-0cfdeb635760%40googlegroups.com?utm_medium=email&utm_source=footer)  
> > .  
> > For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

--  
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).  
To view this discussion on the web visit [https://groups.google.com/d/msgid/elasticsearch/CAGCwEM98B67dX0v%2Bf%2Bv\_02%3Dh7MiKgT%2Bb0%3D8iBd7TGdPR-mhHow%40mail.gmail.com](https://groups.google.com/d/msgid/elasticsearch/CAGCwEM98B67dX0v%2Bf%2Bv_02%3Dh7MiKgT%2Bb0%3D8iBd7TGdPR-mhHow%40mail.gmail.com).  
For more options, visit [https://groups.google.com/d/optout](https://groups.google.com/d/optout).

---

<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, 1:12am UTC](https://discuss.elastic.co/t/efficiency-of-search-vs-get/5389/7 "2017-07-06T01:12:49Z")

</div>