Yes, because only a small portion of that 250ms is spent in the query
parser. Most of it, i would suggest, is spent retrieving and merging
posting lists.
In an inverted index (which Lucene is), you store the list of documents
matching a term against that term - that is your postings list.
When you search against multiple terms, Lucene needs to merge those into
a definitive list of matching documents, and for large numbers of terms,
that can be costly.
Upayavira
On Mon, Jan 4, 2016, at 04:29 PM, Erick Erickson wrote:
> Best of luck with that ;). 250ms isn't bad at all for "searching
> millions of IDs".
> Frankly, I'm not at all sure where I'd even start. With millions of
> search
> terms, I'd have to profile the application to see where it was spending
> the
> time before even starting.
>
> Best,
> Erick
>
> On Mon, Jan 4, 2016 at 5:03 AM, Mugeesh Husain <muge...@gmail.com> wrote:
> >>>This is not a use-case to which Lucene lends itself. However, if you
> >>>must, I would try the terms query parser, which I believe is used like
> >>>this: {!terms f=id}2,3,6,7
> >
> > I did try terms query parser like above, but the problem is performance, i
> > am getting result 250ms but i am looking for a parser which give result
> > within 50ms.
> >
> > I am also looking for custom query parser but i dont know which way i should
> > used that.
> >
> >
> >
> > --
> > View this message in context:
> > http://lucene.472066.n3.nabble.com/how-to-search-miilions-of-record-in-solr-query-tp4248360p4248388.html
> > Sent from the Solr - User mailing list archive at Nabble.com.
