Re: some parent documents

Lucene tends to omit full scans as possible with leap-frogging on skiplists. It will enumerate all *matching* docs O(m) and rank every result with O(log(page size)). ie O(m log p). Early I remember that BJQ enumerated all matching children even most time it's enough find only one, potentially it's

Re: some parent documents

Hi Mikhail et al, I must say that this complexity question is still bugging me, and I wonder if it is possible to get even partial answers in Big-O notation.. Say that we have N (for example 10^6) documents, each having 10 SKUs and each in turn having 10 storage as well as every product having

Re: some parent documents

Hi Mikhail et al, Thanks a lot for sharing the code snippet. I would not have been able to dig this Java file myself to investigate the complexity of the search query. Scanning the code I get a feeling that it is well structured and well thought of. There is a concept like advance (Parent

Re: some parent documents

> > What's happening under the hood of > solr in answering query [1] from [2]? https://github.com/apache/lucene-solr/blob/master/lucene/join/src/java/org/apache/lucene/search/join/ToParentBlockJoinQuery.java#L178 On Wed, Apr 4, 2018 at 3:39 PM, Arturas Mazeika wrote: > Hi

Re: some parent documents

Hi Mikhail et al, Thanks a lot for a very thorough answer. This is an impressive piece of knowledge you just shared. Not surprisingly, I was caught unprepared by the 'v=...' part of the answer. This brought me to the links you posted (starts with http). From those links I went to the more

Re: some parent documents

q=+{!parent which=ntype:p v='+msg:Hello +person:Arturas'} +{!parent which= ntype:p v='+msg:ciao +person:Vai'} On Wed, Apr 4, 2018 at 12:19 PM, Arturas Mazeika wrote: > Hi Mikhail et al, > > It seems to me that the nested documents must include nodes that encode the > level of

Re: some parent documents

Hi Mikhail et al, It seems to me that the nested documents must include nodes that encode the level of nodes (within the document). Therefore, the minimal example must include the node type. Is the following structure sufficient? { "id":1, "ntype":"p", "_childDocuments_": [

Re: some parent documents

Hi Mikhail, Thanks a lot for the reply. You mentioned that q=+{!parent which.. v='+text:hello +person:A'} +{!parent which..v='+text:ciao +person:B'} is the way to go. How would it look like precisely for the following collection? { "id":1, "_childDocuments_": [

Re: some parent documents

Hello, Arturas. TLDR; Please find inline below. On Tue, Apr 3, 2018 at 5:14 PM, Arturas Mazeika wrote: > Hi Solr Fans, > > I am trying to make sense of information retrieval using expressions like > "some parent", "*only parent*", " *all parent*". I am also trying to >