Thanks everyone for the response. On Thu, Jul 18, 2013 at 11:22 AM, Alexandre Rafalovitch <arafa...@gmail.com>wrote:
> You could start from doing id:(12345 23456) to reduce the query length and > possibly speed up parsing. > I didn't know about this syntax- it looks useful. > You could also move the query from 'q' parameter to 'fq' parameter, since > you probably don't care about ranking ('fq' does not rank). > Yes, I don't care about rank, so this helps. > If these are unique every time, you could probably look at not caching > (can't remember exact syntax). > That's all I can think of at the moment without digging deep into why you > need to do this at all. > > Short version of a long story: I'm implementing a graph database on top of solr. Which is not what solr is designed for, I know. This is a case where I'm following a set of edges from a given node to it's 847 children, and I need to get the children. And yes, I've looked at neo4j- it doesn't help. > Regards, > Alex. > > Personal website: http://www.outerthoughts.com/ > LinkedIn: http://www.linkedin.com/in/alexandrerafalovitch > - Time is the quality of nature that keeps events from happening all at > once. Lately, it doesn't seem to be working. (Anonymous - via GTD book) > > > On Thu, Jul 18, 2013 at 10:46 AM, Brian Hurt <bhur...@gmail.com> wrote: > > > I have a situation which is common in our current use case, where I need > to > > get a large number (many hundreds) of documents by id. What I'm doing > > currently is creating a large query of the form "id:12345 OR id:23456 OR > > ..." and sending it off. Unfortunately, this query is taking a long > time, > > especially the first time it's executed. I'm seeing times of like 4+ > > seconds for this query to return, to get 847 documents. > > > > So, my question is: what should I be looking at to improve the > performance > > here? > > > > Brian > > >