Hello all, We've just upgraded to 4.2 from 3.6 and suffered some performance degradation in both indexing and retrieval. We've had to eliminate compression, even supplying our own NoCompression codec since there doesn't appear to be any built in support for this. Hopefully we're not overlooking something with the compression. It did reduce the size of our indexes and thus our memory footprint but we lost more on the LZ4 decompression than we gained by having more free memory.
DocValues didn't help us either. We attempted to create an in-memory cache, using a separate index which we closed afterwards and performing a map reduce to speed up access, but we didn't see any significant performance gains. What about block tree terms? What is the use case for that feature? I noticed that benefits appeared in the spell correction tests but I'm still not clear about how best to employ the codec. Has anyone had any experience with it? Thanks for any and all insights. Best regards, Jim Beale The information contained in this email message, including any attachments, is intended solely for use by the individual or entity named above and may be confidential. If the reader of this message is not the intended recipient, you are hereby notified that you must not read, use, disclose, distribute or copy any part of this communication. If you have received this communication in error, please immediately notify me by email and destroy the original message, including any attachments. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
