lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Engels" <>
Subject RE: non indexed field searching?
Date Wed, 17 May 2006 15:50:59 GMT
That is exactly what I was thinking. Without starting the "Lucene is not a
database..." discussion...

It is how a db works. Use whatever indexes you can to restrict the document
set, then "scan" the documents looking for matches. If you stored EVERY
field in the document (including indexed ones), this might be fairly easy to
do, since evaluating a query expression against a document should be trivial
if every field was available as a stored field.

I am not proposing this be done to Lucene, I was just wondering if anyone
had attempted it.

Has anyone done any sort of performance testing of using MANY fields, and
how that impacts searches, writes, merges? Is it near linear cost for
updates and merges? No additional cost for searches? (So, if you can index
10 fields at 100 docs per minute, you can index 20 fields at 50 docs per
minute - given that all fields are roughly the same size)? What is all of
the additional fields are not indexed, just stored?

-----Original Message-----
From: Yonik Seeley []
Sent: Wednesday, May 17, 2006 10:34 AM
Subject: Re: non indexed field searching?

On 5/17/06, Robert Engels <> wrote:
> I reviewed the solr source (at LOT of the code is amazingly similar to our
> own search server).
> I don't see anything related to searching using non-indexed fields. Could
> you maybe point me at the class(es) that implement this functionality?

Solr doesn't have that functionallity.
I considered it very early on, but it's probably only useful when you
have already narrowed search results sufficiently since retrieving
documents is not a fast operation.

Can't you just index fields you need to search on?


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message