[ 
https://issues.apache.org/jira/browse/SOLR-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14202936#comment-14202936
 ] 

Steve Davids commented on SOLR-4587:
------------------------------------

I agree that the Luwak approach provides clever performance optimizations by 
removing unnecessary queries upfront. Though, Luwak doesn't really solve 
providing "percolator-like functionality", just provides an optimized matching 
algorithm. There is a decent amount of work here to allow clients to register 
queries in a Solr cluster and provide an API to pass a document and have it get 
matched against registered queries in a distributed manor, none of which is 
handled by Luwak. I personally believe this ticket can be implemented without 
Luwak's optimizations and provide value. We could provide a usage caveat that 
you might not want to register more than 20k queries per shard or so, or if 
they want to register more queries they can shard out their profiling/matcher 
collection to take advantage of additional hardware. We can provide an initial 
implementation then optimize the matching once Luwak dependencies are 
completed, but from an outside-in perspective the API would remain the same but 
matching would just be faster at a future point. 

Does it make sense to others to start with an initial approach then provide 
optimizations in future releases just as long as the API remains the same?

> Implement Saved Searches a la ElasticSearch Percolator
> ------------------------------------------------------
>
>                 Key: SOLR-4587
>                 URL: https://issues.apache.org/jira/browse/SOLR-4587
>             Project: Solr
>          Issue Type: New Feature
>          Components: SearchComponents - other, SolrCloud
>            Reporter: Otis Gospodnetic
>             Fix For: Trunk
>
>
> Use Lucene MemoryIndex for this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to