"id" field is not serial, it generated randomly.. so range queries on this field are almost useless. I mentioned TrieField, because solr.LongField is internally implemented as a string, while solr.TrieLongField is a number. It might improve performace, even without setting a precisionStep...
On Thu, Jan 24, 2013 at 3:31 AM, Otis Gospodnetic < otis.gospodne...@gmail.com> wrote: > Hi, > > I think trie type fields add value only if you do range queries in them and > it sounds like that is bit your use case. > > Otis > Solr & ElasticSearch Support > http://sematext.com/ > On Jan 23, 2013 2:53 PM, "Isaac Hebsh" <isaac.he...@gmail.com> wrote: > > > Hi, > > > > In my use case, Solr have to to return only the "id" field, as a response > > for queries. However, it should return 1000 docs at once (rows=1000). > > > > My id field is defined as StrField, due to external systems constraints. > > > > I guess that TrieFields are more efficient than StrFields. > *Theoretically*, > > the field content can be retrieved without loading the stored field. > > > > Should I strive that the id will be managed as a number, or it has no > > contribution to performance (search & retrieve times)? > > > > (Yes, I know that lucene has an internal id mechanism. I think it is not > > relevant to my question...) > > > > > > - Isaac. > > >
