lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <rcm...@gmail.com>
Subject Re: FieldCache future?
Date Thu, 23 Feb 2012 18:41:19 GMT
On Thu, Feb 23, 2012 at 1:32 PM, Ryan McKinley <ryantxu@gmail.com> wrote:
> In LUCENE-3360, there is discussion that DocValues could be used to
> replace the existing FieldCache.  This seems like is a great
> direction, but I am not sure how people see this getting implemented.
>
> Is the suggestion to add something like:
>  DocValues fieldCache(String field);
> to AtomicReader?

No, my suggestion is not to add anything to indexreader at all.
IndexReader is decoupled from FieldCache, I think we should keep it
that way.

You can already sort, group, etc on docvalues fields... so I'm arguing
that users should say up front which fields they are going to
sort/group on
so we can actually be an index and compute this stuff at indexing
time, rather than uninverting at search time (and do this stuff more
effectively with ideas like LUCENE-3729).

Thus this "compute/uninvert on the fly" fieldcache could be moved
somewhere else.

Grouping etc could work solely on a docvalues api and maybe they have
a special ctor to take a SortedBytes impl (and fieldcache implements
the docvalues api or some other backwards mechanism).
This would remove the redundant implementations (both fieldcache and
DV implementations) in stuff like grouping, join, sort, etc

Sure its a change, but so is making IndexReader read-only and other
things we have done.

-- 
lucidimagination.com

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


Mime
View raw message