Hi Adrien,-
Great, thanks.
Best regards
> On Oct 12, 2020, at 1:13 PM, Adrien Grand wrote:
>
> It's not the most visible place, but the paper is referenced in the source
> code of the class that implements BM WAND
> https://urldefense.com/v3/__https://github.com/apache/lucene-solr/blob/907d1142
It's not the most visible place, but the paper is referenced in the source
code of the class that implements BM WAND
https://github.com/apache/lucene-solr/blob/907d1142fa435451b40c072f1d445ee868044b15/lucene/core/src/java/org/apache/lucene/search/WANDScorer.java#L29-L44
.
On Mon, Oct 12, 2020 at 6
Hi Uwe,-
i see, thanks for the info, i wish the documentation mentions this new
algorithm by referencing the papers (i have the papers).
Best regards
On 10/12/20 12:27 PM, Uwe Schindler wrote:
There's not much new documentation, it works behind scenes, except that
IndexSearcher.search and
There's not much new documentation, it works behind scenes, except that
IndexSearcher.search and TopDocs class no longer return an absolute count for
totalHits and instead this class:
https://lucene.apache.org/core/8_0_0/core/org/apache/lucene/search/TotalHits.html
Uwe
Am October 12, 2020 4:22
Hi Uwe,-
Could You please point me to the class documentation please?
Best regards
On 10/12/20 12:16 PM, Uwe Schindler wrote:
BMW support is in Lucene since version 8.0.
Uwe
Am October 12, 2020 4:08:42 PM UTC schrieb baris.ka...@oracle.com:
Hi,-
Is BMW (Block Max Wand) support
BMW support is in Lucene since version 8.0.
Uwe
Am October 12, 2020 4:08:42 PM UTC schrieb baris.ka...@oracle.com:
>Hi,-
>
> Is BMW (Block Max Wand) support only for Solr?
>
>https://lucene.apache.org/solr/guide/8_6/solr-upgrade-notes.html
>
>This pages says "also" so it implies support for Luce
Hi,-
Is BMW (Block Max Wand) support only for Solr?
https://lucene.apache.org/solr/guide/8_6/solr-upgrade-notes.html
This pages says "also" so it implies support for Lucene, too, right?
Best regards
-
To unsubscribe, e-mai
I see. So I'm most likely rarely skipping a block's worth of docs, so using
advance() vs nextDoc() doesn't make much of a difference.
All good to know. Thank you.
On Mon, Oct 12, 2020 at 11:42 AM Adrien Grand wrote:
> advanceShallow is indeed faster than advance because it does less:
> advanceSh
advanceShallow is indeed faster than advance because it does less:
advanceShallow only advances the cursor for block-max metadata, this allows
reasoning about maximum scores without actually advancing the doc ID.
advanceShallow is implicitly called via advance.
If your optimization rarely helps sk
Thanks Adrien. Very helpful.
The doc for ImpactSource.advanceShallow says it's more efficient than
DocIDSetIterator.advance.
Is that because advanceShallow is skipping entire blocks at a time, whereas
advance is not?
One possible optimization I've explored involves skipping pruned docIDs. I
tried t
> https://issues.apache.org/jira/browse/SOLR-11831 I collaborated on Las Vegas
> patch, I don't think that patch will be merged - it modifies too many things
> in the core - we ended up reimplementing it as a standalone plugin.
Also keep in mind that the patch makes the difference only if you are
Thank you very much for helping!
There isn't much I can add about my use case. I have user-generated video
titles and hash codes by which I can understand that these are the same
videos. Users search videos by title and I should return the top 1000
unique videos to them.
I will try to use groupin
Hi Everyone
I have a use case where I need to provide suggestions (autocomplete) on
multivalued tags. For example if i have documents as below
docId| users | tags (multivalued/array field)
---
doc1 [user1, user2,user3] one, two, thirty
13 matches
Mail list logo
