o:ysee...@gmail.com]
> Sent: June-09-14 10:50 AM
> To: solr-user@lucene.apache.org
> Subject: Re: ANN: Solr Next
>
> On Tue, Jan 7, 2014 at 1:53 PM, Yonik Seeley wrote:
> [...]
> > Next major feature: Native Code Optimizations.
> > In addition to moving more
On Tue, Jan 7, 2014 at 1:53 PM, Yonik Seeley wrote:
[...]
> Next major feature: Native Code Optimizations.
> In addition to moving more large data structures off-heap(like
> UnInvertedField?), I am planning to implement native code
> optimizations for certain hotspots. Native code faceting would
That would be cool, but seems it would only work for simple term queries.
I guess having both would be best.
http://heliosearch.org -- off-heap filters for solr
-Yonik
On Mon, Jan 13, 2014 at 2:21 PM, Mikhail Khludnev
wrote:
> Yonik,
> Don't you think that proper codec format can get the compar
Yonik,
Don't you think that proper codec format can get the comparable gain
without changes in design?
https://issues.apache.org/jira/browse/LUCENE-5052
On Mon, Jan 13, 2014 at 9:15 PM, Yonik Seeley wrote:
> Update on the my initial performance findings for off-heap filters:
> http://heliosearc
Update on the my initial performance findings for off-heap filters:
http://heliosearch.org/off-heap-filters/
-Yonik
http://heliosearch.org -- making solr shine
On Tue, Jan 7, 2014 at 1:53 PM, Yonik Seeley wrote:
> Off-Heap Filters:
> JVMs have never been good at dealing with large heaps. Large
It's time to start working on the next major evolution of Solr (much
as we did years ago for the SolrCloud effort). To kick things off,
I've started a project on github and implemented "off-heap" filters,
as a first step toward taking performance to the next level.
For a number of reasons, we fel
