lucene-solr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r823705 - /lucene/solr/trunk/CHANGES.txt
Date Fri, 09 Oct 2009 21:45:49 GMT
Author: yonik
Date: Fri Oct  9 21:45:49 2009
New Revision: 823705

doc - per-segment fieldcache issues


Modified: lucene/solr/trunk/CHANGES.txt
--- lucene/solr/trunk/CHANGES.txt (original)
+++ lucene/solr/trunk/CHANGES.txt Fri Oct  9 21:45:49 2009
@@ -30,6 +30,20 @@
 faster for most cases.  One can revert to the previous algorithm (which has
 also been improved somewhat) by adding facet.method=enum to the request.
+Searching and sorting is now done on a per-segment basis, meaning that
+the FieldCache entries used for sorting and for function queries are
+created and used per-segment and can be reused for segments that don't
+change between index updates.  While generally beneficial, this can lead
+to increased memory usage over 1.3 in certain scenarios: 
+  1) A single valued field that was used for both sorting and faceting
+in 1.3 would have used the same top level FieldCache entry.  In 1.4, 
+sorting will use entries at the segment level while faceting will still
+use entries at the top reader level, leading to increased memory usage.
+  2) Certain function queries such as ord() and rord() require a top level
+FieldCache instance and can thus lead to increased memory usage.  Consider
+replacing ord() and rord() with alternatives, such as function queries
+based on ms() for date boosting.
 If you use custom Tokenizer or TokenFilter components in a chain specified in
 schema.xml, they must support reusability.  If your Tokenizer or TokenFilter
 maintains state, it should implement reset().  If your TokenFilteFactory does

View raw message