On 7/10/06, David Balmain <dbalmain.ml@gmail.com> wrote:
> I don't think declaring all fields up front is necessary for
> substantial optimizations. I've found that the key to some really good
> optimizations is having constant field numbers. That is, once a field
> is added to the index it is assigned a field number and it it keeps
> that field number for the life of the index.

I can sort of see how this would work when adding documents to a singe index.
What about merging indicies via IndexWriter.addIndexes()?  I guess
this would require keeping the current way of merging around as a
fallback?

Does this mess up opening a MultiReader on multiple indicies
constructed at different times?  This is a common thing for people to
do.

> This allows one
> FieldInfos object per index instead of one per segment.

So when a new segment is written, the global FieldInfos may need to be updated.
I guess this should be written after the new segment and before the
"segments" file.

>  As I mentioned
> earlier this greatly optimizes the merging of term vectors and stored
> fields. The only problem I could find with this solution is that
> fields are no longer in alphabetical order in the term dictionary but
> I couldn't think of a use-case where this is necessary although I'm
> sure there probably is one.

Isn't an ordered term dictionary necessary to do lookups?

-Yonik
http://incubator.apache.org/solr Solr, the open-source Lucene search server

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