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 [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 17, 2006 10:34 AM To: java-dev@lucene.apache.org Subject: Re: non indexed field searching? On 5/17/06, Robert Engels <[EMAIL PROTECTED]> 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? -Yonik --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
