Thanks Shawn! I have created these 2 tickets: https://issues.apache.org/jira/browse/LUCENE-5299 (the refactoring) https://issues.apache.org/jira/browse/SOLR-5372 (so Solr can take advantage of it)
On Mon, Oct 21, 2013 at 9:48 AM, Shawn Heisey <s...@elyograg.org> wrote: > On 10/21/2013 7:10 AM, Shikhar Bhushan wrote: > > I wanted to add a note as to the motivation for these changes. > > Essentially we should be able to scale-up better with Solr/Lucene and > > not just scale-out by sharding. With sharding one enters distributed > > systems territory with all the pitfalls and failure conditions, which is > > not ideal especially if your index is not large enough to warrant > > it. The next frontier seems to be to utilize multiple CPU cores for > > performing a search request's legwork, and the results are very > > promising - 2-3x speedups in many cases! > > > > Would be great to get a sense of committer interest :) Let me know if I > > should just open a JIRA with patches. > > Although I do not have much understanding of the deep internals, I think > I can safely say this: It is almost never a mistake to open an issue in > Jira and attach a patch, even if the idea ultimately never gets used. > > In cases where a patch shows significant performance gains, the code > needs careful review to make sure that it doesn't break anything or make > radical changes to the API. As you might know, major changes to the API > are typically reserved for the next major release, unless the old API > can easily be kept and deprecated. > > If it's a very good patch, the performance improvement will still be > significant after any problems are fixed. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
