> there is a entire RAM resident part and a Iterator API that reads /
> streams data directly from disk.
> look at DocValuesEnum vs, Source
Nice, thanks!
On Thu, Feb 3, 2011 at 12:20 AM, Simon Willnauer
wrote:
> On Thu, Feb 3, 2011 at 3:23 AM, Jason Rutherglen
> wrote:
>> Is it? I thought it w
On Thu, Feb 3, 2011 at 3:23 AM, Jason Rutherglen
wrote:
> Is it? I thought it would load the values into heap RAM like the
> field cache and in addition save the values to disk? Does it also
> read the values directly from disk?
there is a entire RAM resident part and a Iterator API that reads
On Wed, Feb 2, 2011 at 9:23 PM, Jason Rutherglen wrote:
> Is it? I thought it would load the values into heap RAM like the
> field cache and in addition save the values to disk? Does it also
> read the values directly from disk?
>
Loading into memory is a separate optional part (i.e. loading a
Is it? I thought it would load the values into heap RAM like the
field cache and in addition save the values to disk? Does it also
read the values directly from disk?
On Wed, Feb 2, 2011 at 2:00 PM, Yonik Seeley wrote:
> That's exactly what the CSF feature is for, right? (docvalues branch)
>
>
That's exactly what the CSF feature is for, right? (docvalues branch)
-Yonik
http://lucidimagination.com
On Wed, Feb 2, 2011 at 1:03 PM, Jason Rutherglen wrote:
> I'm curious if there's a new way (using flex or term states) to store
> IDs alongside a document and retrieve the IDs of the top N
I'm curious if there's a new way (using flex or term states) to store
IDs alongside a document and retrieve the IDs of the top N results?
The goal would be to minimize HD seeks, and not use field caches
(because they consume too much heap space) or the doc stores (which
require two seeks). One pos
