The new Parallell SQL feature of 6.0? Also query-time on top of streaming,
don’t know performance...
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
> 1. feb. 2016 kl. 07.37 skrev Sathyakumar Seshachalam
> :
>
> Thanks, query time joins are not an option for me, beca
Thanks, query time joins are not an option for me, because of the size of
the index and hence the join performance,
I will look at Siren.
On 29/01/16, 10:16 PM, "Alessandro Benedetti"
wrote:
>Probably if you are interested in a many-to-many relation, you could be
>interested in the query time
Hello,
This implies that an indexing extracts cliques of bipartite graph. Then,
every clique goes as a single block with a sentinel parent document. And
this parent document can carry incidence matrix as, let's say, binary
docvalues. Then, a bunch of custom components can to handle this model.
On
Probably if you are interested in a many-to-many relation, you could be
interested in the query time join.
it has been the first type of join integrated in Solr.
It allow you to avoid redundancies.
It's slower than block join, but it doesn't force you to any specific
indexing approach.
It became le
If you wish to change, add, or delete a child or change the parent you must
do an add of the entire block again with both the parent and all children.
This is because the efficiency of Block Join comes from the documents being
adjacent in Lucene and segments are immutable in Lucene, so the entire
b
Hi,
Am trying to investigate the possibility of using Block Join query parser in a
many-to-many relation scenario.
Observation is that when a document is added as a child to more than one parent
document (I use Solrj to do this), I seem to get two copies of the child
document. Can this be avoid
