Details

Type: Improvement

Status: Open

Priority: Minor

Resolution: Unresolved

Affects Version/s: 4.7.1

Fix Version/s: None

Component/s: SearchComponents  other

Labels:
Description
Multiple performance enhancements to Solr String faceting.
 Sparse counters, switching the constant time overhead of extracting topX terms with time overhead linear to result set size
 Counter reuse for reduced garbage collection and lower percall overhead
 Optional counter packing, trading speed for space
 Improved distribution count logic, greatly improving the performance of distributed faceting
 Insegment threaded faceting
 Regexp based white and blacklisting of facet terms
 Heuristic faceting for large result sets
Currently implemented for Solr 4.10. Source, detailed description and directly usable WAR at http://tokee.github.io/lucenesolr/
This project has grown beyond a simple patch and will require a fair amount of cooperation with a committer to get into Solr. Splitting into smaller issues is a possibility.
Activity
 All
 Comments
 Work Log
 History
 Activity
 Transitions
Toke Eskildsen
made changes 
Description 
Multiple performance enhancements to Solr String faceting.
* Sparse counters, switching the constant time overhead of extracting topX terms with time linear to result set size * Counter reuse for reduced garbage collection and lower percall overhead * Optional counter packing, trading speed for space * Improved distribution count logic, greatly reducing the overhead of distributed faceting * Insegment threaded faceting * Regexp based white and blacklisting of facet terms * Heuristic faceting for large result sets Currently implemented for Solr 4.10 and available as source and directly usable WAR at http://tokee.github.io/lucenesolr/ 
Multiple performance enhancements to Solr String faceting.
* Sparse counters, switching the constant time overhead of extracting topX terms with time overhead linear to result set size * Counter reuse for reduced garbage collection and lower percall overhead * Optional counter packing, trading speed for space * Improved distribution count logic, greatly improving the performance of distributed faceting * Insegment threaded faceting * Regexp based white and blacklisting of facet terms * Heuristic faceting for large result sets Currently implemented for Solr 4.10. Source, detailed description and directly usable WAR at http://tokee.github.io/lucenesolr/ This project has grown beyond a simple patch and will require a fair amount of cooperation with a committer to get into Solr. Splitting into smaller issues is a possibility. 
Toke Eskildsen
made changes 
Description 
Field based faceting in Solr has two phases: Collecting counts for tags in facets and extracting the requested tags.
The execution time for the collecting phase is approximately linear to the number of hits and the number of references from hits to tags. This phase is not the focus here. The extraction time scales with the number of unique tags in the search result, but is also heavily influenced by the total number of unique tags in the facet as every counter, 0 or not, is visited by the extractor (at least for count order). For fields with millions of unique tag values this means 10s of milliseconds added to the minimum response time (see https://sbdevel.wordpress.com/2014/03/18/sparsefacetcountingonarealindex/ for a test on a corpus with 7M unique values in the facet). The extractor needs to visit every counter due to the current counter structure being a plain intarray of size #unique_tags. Switching to a sparse structure, where only the tag counters > 0 are visited, makes the extraction time linear to the number of unique tags in the result set. Unfortunately the number of unique tags in the result set is unknown at collect time, so it is not possible to reliably select sparse counting vs. full counting up front. Luckily there exists solutions for sparse sets that has the property of switching to nonsparsemode without a switchpenalty, when the sparsethreshold is exceeded (see http://programmingpraxis.com/2012/03/09/sparsesets/ for an example). This JIRA aims to implement this functionality in Solr. Current status: Sparse counting is implemented for field cache faceting, both single and multivalue, with and without docvalues. Sort by count only. The patch applies cleanly to Solr 4.6.1 and should integrate well with everything as all functionality is unchanged. After patching, the following new parameters are possible: * facet.sparse=true enables sparse faceting. * facet.sparse.mintags=10000 the minimum amount of unique tags in the given field for sparse faceting to be active. This is used for autoselecting whether sparse should be used or not. * facet.sparse.fraction=0.08 the overhead used for the sparse tracker. Setting this too low means that only very small result sets are handled as sparse. Setting this too high will result in a large performance penalty if the result set blows the sparse tracker. Values between 0.04 and 0.1 seems to work well. * facet.sparse.packed=true use PackecInts for counters instead of int[]. This saves memory, but performance will differ. Whether performance will be better or worse depends on the corpus. Experiment with it. * facet.sparse.cutoff=0.90 if the estimated number (based on hitcount) of unique tags in the search result exceeds this fraction of the sparse tracker, do not perform sparse tracking. The estimate is based on the assumption that references from documents to tags are distributed randomly. * facet.sparse.pool.size=2 the maximum amount of sparse trackers to clear and keep in memory, ready for usage. Clearing and reusing a counter is faster that allocating it fresh from the heap. Setting the pool size to 0 means than a new sparse counter will be allocated each time, just as standard Solr faceting works. * facet.sparse.stats=true adds a special tag with timing statistics for sparse faceting. * facet.sparse.stats.reset=true resets the timing statistics and clears the pool. The parameters needs to be given together with standard faceting parameters, such as facet=true&facet.field=myfield&facet.mincount=1&facet.sort=true. The defaults should be usable, so simply appending facet.sparse=true to the URL is a good start. 
Multiple performance enhancements to Solr String faceting.
* Sparse counters, switching the constant time overhead of extracting topX terms with time linear to result set size * Counter reuse for reduced garbage collection and lower percall overhead * Optional counter packing, trading speed for space * Improved distribution count logic, greatly reducing the overhead of distributed faceting * Insegment threaded faceting * Regexp based white and blacklisting of facet terms * Heuristic faceting for large result sets Currently implemented for Solr 4.10 and available as source and directly usable WAR at http://tokee.github.io/lucenesolr/ 
Toke Eskildsen
made changes 
Attachment  SOLR5894.patch [ 12653779 ] 
Toke Eskildsen
made changes 
Attachment  SOLR5894.patch [ 12651117 ] 
Toke Eskildsen
made changes 
Labels  facetedsearch faceting memory performance 
Toke Eskildsen
made changes 
Fix Version/s  4.7.1 [ 12326521 ] 
Toke Eskildsen
made changes 
Affects Version/s  4.7.1 [ 12326521 ]  
Affects Version/s  4.7 [ 12325573 ]  
Affects Version/s  4.6.1 [ 12325762 ] 
Toke Eskildsen
made changes 
Fix Version/s  4.7.1 [ 12326521 ]  
Fix Version/s  4.6.1 [ 12325762 ] 
Toke Eskildsen
made changes 
Description 
Field based faceting in Solr has two phases: Collecting counts for tags in facets and extracting the requested tags.
The execution time for the collecting phase is approximately linear to the number of hits and the number of references from hits to tags. This phase is not the focus here. The extraction time scales with the number of unique tags in the search result, but is also heavily influenced by the total number of unique tags in the facet as every counter, 0 or not, is visited by the extractor (at least for count order). For fields with millions of unique tag values this means 10s of milliseconds added to the minimum response time (see https://sbdevel.wordpress.com/2014/03/18/sparsefacetcountingonarealindex/ for a test on a corpus with 7M unique values in the facet). The extractor needs to visit every counter due to the current counter structure being a plain intarray of size #unique_tags. Switching to a sparse structure, where only the tag counters > 0 are visited, makes the extraction time linear to the number of unique tags in the result set. Unfortunately the number of unique tags in the result set is unknown at collect time, so it is not possible to reliably select sparse counting vs. full counting up front. Luckily there exists solutions for sparse sets that has the property of switching to nonsparsemode without a switchpenalty, when the sparsethreshold is exceeded (see http://programmingpraxis.com/2012/03/09/sparsesets/ for an example). This JIRA aims to implement this functionality in Solr. Current status: Sparse counting is implemented for field cache faceting, both single and multivalue, with and without docvalues. Sort by count only. The patch applies cleanly to Solr 4.6.1 and should integrate well with everything as all functionality is unchanged. After patching, the following new parameters are possible: * facet.sparse=true enables sparse faceting. * facet.sparse.mintags=10000 the minimum amount of unique tags in the given field for sparse faceting to be active. This is used for autoselecting whether sparse should be used or not. * facet.sparse.fraction=0.08 the overhead used for the sparse tracker. Setting this too low means that only very small result sets are handled as sparse. Setting this too high will result in a large performance penalty if the result set blows the sparse tracker. Values between 0.04 and 0.1 seems to work well. * facet.sparse.cutoff=0.90 if the estimated number (based on hitcount) of unique tags in the search result exceeds this fraction of the sparse tracker, do not perform sparse tracking. The estimate is based on the assumption that references from documents to tags are distributed randomly. * facet.sparse.pool.size=2 the maximum amount of sparse trackers to clear and keep in memory, ready for usage. Clearing and reusing a counter is faster that allocating it fresh from the heap. Setting the pool size to 0 means than a new sparse counter will be allocated each time, just as standard Solr faceting works. * facet.sparse.stats=true adds a special tag with timing statistics for sparse faceting. * facet.sparse.stats.reset=true resets the timing statistics and clears the pool. The parameters needs to be given together with standard faceting parameters, such as facet=true&facet.field=myfield&facet.mincount=1&facet.sort=true. The defaults should be usable, so simply appending facet.sparse=true to the URL is a good start. 
Field based faceting in Solr has two phases: Collecting counts for tags in facets and extracting the requested tags.
The execution time for the collecting phase is approximately linear to the number of hits and the number of references from hits to tags. This phase is not the focus here. The extraction time scales with the number of unique tags in the search result, but is also heavily influenced by the total number of unique tags in the facet as every counter, 0 or not, is visited by the extractor (at least for count order). For fields with millions of unique tag values this means 10s of milliseconds added to the minimum response time (see https://sbdevel.wordpress.com/2014/03/18/sparsefacetcountingonarealindex/ for a test on a corpus with 7M unique values in the facet). The extractor needs to visit every counter due to the current counter structure being a plain intarray of size #unique_tags. Switching to a sparse structure, where only the tag counters > 0 are visited, makes the extraction time linear to the number of unique tags in the result set. Unfortunately the number of unique tags in the result set is unknown at collect time, so it is not possible to reliably select sparse counting vs. full counting up front. Luckily there exists solutions for sparse sets that has the property of switching to nonsparsemode without a switchpenalty, when the sparsethreshold is exceeded (see http://programmingpraxis.com/2012/03/09/sparsesets/ for an example). This JIRA aims to implement this functionality in Solr. Current status: Sparse counting is implemented for field cache faceting, both single and multivalue, with and without docvalues. Sort by count only. The patch applies cleanly to Solr 4.6.1 and should integrate well with everything as all functionality is unchanged. After patching, the following new parameters are possible: * facet.sparse=true enables sparse faceting. * facet.sparse.mintags=10000 the minimum amount of unique tags in the given field for sparse faceting to be active. This is used for autoselecting whether sparse should be used or not. * facet.sparse.fraction=0.08 the overhead used for the sparse tracker. Setting this too low means that only very small result sets are handled as sparse. Setting this too high will result in a large performance penalty if the result set blows the sparse tracker. Values between 0.04 and 0.1 seems to work well. * facet.sparse.packed=true use PackecInts for counters instead of int[]. This saves memory, but performance will differ. Whether performance will be better or worse depends on the corpus. Experiment with it. * facet.sparse.cutoff=0.90 if the estimated number (based on hitcount) of unique tags in the search result exceeds this fraction of the sparse tracker, do not perform sparse tracking. The estimate is based on the assumption that references from documents to tags are distributed randomly. * facet.sparse.pool.size=2 the maximum amount of sparse trackers to clear and keep in memory, ready for usage. Clearing and reusing a counter is faster that allocating it fresh from the heap. Setting the pool size to 0 means than a new sparse counter will be allocated each time, just as standard Solr faceting works. * facet.sparse.stats=true adds a special tag with timing statistics for sparse faceting. * facet.sparse.stats.reset=true resets the timing statistics and clears the pool. The parameters needs to be given together with standard faceting parameters, such as facet=true&facet.field=myfield&facet.mincount=1&facet.sort=true. The defaults should be usable, so simply appending facet.sparse=true to the URL is a good start. 
Toke Eskildsen
made changes 
Attachment  SOLR5894.patch [ 12639784 ]  
Attachment  SOLR5894_test.zip [ 12639785 ] 
Toke Eskildsen
made changes 
Description 
Field based faceting in Solr has two phases: Collecting counts for tags in facets and extracting the requested tags.
The execution time for the collecting phase is approximately linear to the number of hits and the number of references from hits to tags. This phase is not the focus here. The extraction time scales with the number of unique tags in the search result, but is also heavily influenced by the total number of unique tags in the facet as every counter, 0 or not, is visited by the extractor (at least for count order). For fields with millions of unique tag values this means 10s of milliseconds added to the minimum response time (see https://sbdevel.wordpress.com/2014/03/18/sparsefacetcountingonarealindex/ for a test on a corpus with 7M unique values in the facet). The extractor needs to visit every counter due to the current counter structure being a plain intarray of size #unique_tags. Switching to a sparse structure, where only the tag counters > 0 are visited, makes the extraction time linear to the number of unique tags in the result set. Unfortunately the number of unique tags in the result set is unknown at collect time, so it is not possible to reliably select sparse counting vs. full counting up front. Luckily there exists solutions for sparse sets that has the property of switching to nonsparsemode without a switchpenalty, when the sparsethreshold is exceeded (see http://programmingpraxis.com/2012/03/09/sparsesets/ for an example). This JIRA aims to implement this functionality in Solr. Current status: Sparse counting is implemented for field cache faceting, both single and multivalue, with and without docvalues. Sort by count only. The patch applies cleanly to Solr 4.6.1 and should integrate well with everything as all functionality is unchanged. After patching, the following new parameters are possible: * facet.sparse=true enables sparse faceting. * facet.sparse.mintags=10000 the minimum amount of unique tags in the given field for sparse faceting to be active. This is used for autoselecting whether sparse should be used or not. * facet.sparse.fraction=0.08 the overhead used for the sparse tracker. Setting this too low means that only very small result sets are handled as sparse. Setting this too high will result in a large performance penalty if the result set blows the sparse tracker. Values between 0.04 and 0.1 seems to work well. * facet.sparse.pool.size=2 the maximum amount of sparse trackers to clear and keep in memory, ready for usage. Clearing and reusing a counter is faster that allocating it fresh from the heap. Setting the pool size to 0 means than a new sparse counter will be allocated each time, just as standard Solr faceting works. * facet.sparse.stats=true adds a special tag with timing statistics for sparse faceting. * facet.sparse.stats.reset=true resets the timing statistics and clears the pool. The parameters needs to be given together with standard faceting parameters, such as facet=true&facet.field=myfield&facet.mincount=1&facet.sort=true. The defaults should be usable, so simply appending facet.sparse=true to the URL is a good start. 
Field based faceting in Solr has two phases: Collecting counts for tags in facets and extracting the requested tags.
The execution time for the collecting phase is approximately linear to the number of hits and the number of references from hits to tags. This phase is not the focus here. The extraction time scales with the number of unique tags in the search result, but is also heavily influenced by the total number of unique tags in the facet as every counter, 0 or not, is visited by the extractor (at least for count order). For fields with millions of unique tag values this means 10s of milliseconds added to the minimum response time (see https://sbdevel.wordpress.com/2014/03/18/sparsefacetcountingonarealindex/ for a test on a corpus with 7M unique values in the facet). The extractor needs to visit every counter due to the current counter structure being a plain intarray of size #unique_tags. Switching to a sparse structure, where only the tag counters > 0 are visited, makes the extraction time linear to the number of unique tags in the result set. Unfortunately the number of unique tags in the result set is unknown at collect time, so it is not possible to reliably select sparse counting vs. full counting up front. Luckily there exists solutions for sparse sets that has the property of switching to nonsparsemode without a switchpenalty, when the sparsethreshold is exceeded (see http://programmingpraxis.com/2012/03/09/sparsesets/ for an example). This JIRA aims to implement this functionality in Solr. Current status: Sparse counting is implemented for field cache faceting, both single and multivalue, with and without docvalues. Sort by count only. The patch applies cleanly to Solr 4.6.1 and should integrate well with everything as all functionality is unchanged. After patching, the following new parameters are possible: * facet.sparse=true enables sparse faceting. * facet.sparse.mintags=10000 the minimum amount of unique tags in the given field for sparse faceting to be active. This is used for autoselecting whether sparse should be used or not. * facet.sparse.fraction=0.08 the overhead used for the sparse tracker. Setting this too low means that only very small result sets are handled as sparse. Setting this too high will result in a large performance penalty if the result set blows the sparse tracker. Values between 0.04 and 0.1 seems to work well. * facet.sparse.cutoff=0.90 if the estimated number (based on hitcount) of unique tags in the search result exceeds this fraction of the sparse tracker, do not perform sparse tracking. The estimate is based on the assumption that references from documents to tags are distributed randomly. * facet.sparse.pool.size=2 the maximum amount of sparse trackers to clear and keep in memory, ready for usage. Clearing and reusing a counter is faster that allocating it fresh from the heap. Setting the pool size to 0 means than a new sparse counter will be allocated each time, just as standard Solr faceting works. * facet.sparse.stats=true adds a special tag with timing statistics for sparse faceting. * facet.sparse.stats.reset=true resets the timing statistics and clears the pool. The parameters needs to be given together with standard faceting parameters, such as facet=true&facet.field=myfield&facet.mincount=1&facet.sort=true. The defaults should be usable, so simply appending facet.sparse=true to the URL is a good start. 
Toke Eskildsen
made changes 
Attachment  SOLR5894.patch [ 12638465 ]  
Attachment  SOLR5894_test.zip [ 12638466 ]  
Attachment  sparse_2000000docs_fc_cutoff_20140403145412.png [ 12638467 ] 
Toke Eskildsen
made changes 
Description 
Field based faceting in Solr has two phases: Collecting counts for tags in facets and extracting the requested tags.
The execution time for the collecting phase is approximately linear to the number of hits and the number of references from hits to tags. This phase is not the focus here. The extraction time scales with the number of unique tags in the search result, but is also heavily influenced by the total number of unique tags in the facet as every counter, 0 or not, is visited by the extractor (at least for count order). For fields with millions of unique tag values this means 10s of milliseconds added to the minimum response time (see https://sbdevel.wordpress.com/2014/03/18/sparsefacetcountingonarealindex/ for a test on a corpus with 7M unique values in the facet). The extractor needs to visit every counter due to the current counter structure being a plain intarray of size #unique_tags. Switching to a sparse structure, where only the tag counters > 0 are visited, makes the extraction time linear to the number of unique tags in the result set. Unfortunately the number of unique tags in the result set is unknown at collect time, so it is not possible to reliably select sparse counting vs. full counting up front. Luckily there exists solutions for sparse sets that has the property of switching to nonsparsemode without a switchpenalty, when the sparsethreshold is exceeded (see http://programmingpraxis.com/2012/03/09/sparsesets/ for an example). This JIRA aims to implement this functionality in Solr. Current status: Sparse counting is implemented for field cache faceting, both single and multivalue, with and without docvalues. The patch applies cleanly to Solr 4.6.1 and should integrate well with everything as all functionality is unchanged. After patching, the following new parameters are possible: 
Field based faceting in Solr has two phases: Collecting counts for tags in facets and extracting the requested tags.
The execution time for the collecting phase is approximately linear to the number of hits and the number of references from hits to tags. This phase is not the focus here. The extraction time scales with the number of unique tags in the search result, but is also heavily influenced by the total number of unique tags in the facet as every counter, 0 or not, is visited by the extractor (at least for count order). For fields with millions of unique tag values this means 10s of milliseconds added to the minimum response time (see https://sbdevel.wordpress.com/2014/03/18/sparsefacetcountingonarealindex/ for a test on a corpus with 7M unique values in the facet). The extractor needs to visit every counter due to the current counter structure being a plain intarray of size #unique_tags. Switching to a sparse structure, where only the tag counters > 0 are visited, makes the extraction time linear to the number of unique tags in the result set. Unfortunately the number of unique tags in the result set is unknown at collect time, so it is not possible to reliably select sparse counting vs. full counting up front. Luckily there exists solutions for sparse sets that has the property of switching to nonsparsemode without a switchpenalty, when the sparsethreshold is exceeded (see http://programmingpraxis.com/2012/03/09/sparsesets/ for an example). This JIRA aims to implement this functionality in Solr. Current status: Sparse counting is implemented for field cache faceting, both single and multivalue, with and without docvalues. Sort by count only. The patch applies cleanly to Solr 4.6.1 and should integrate well with everything as all functionality is unchanged. After patching, the following new parameters are possible: * facet.sparse=true enables sparse faceting. * facet.sparse.mintags=10000 the minimum amount of unique tags in the given field for sparse faceting to be active. This is used for autoselecting whether sparse should be used or not. * facet.sparse.fraction=0.08 the overhead used for the sparse tracker. Setting this too low means that only very small result sets are handled as sparse. Setting this too high will result in a large performance penalty if the result set blows the sparse tracker. Values between 0.04 and 0.1 seems to work well. * facet.sparse.pool.size=2 the maximum amount of sparse trackers to clear and keep in memory, ready for usage. Clearing and reusing a counter is faster that allocating it fresh from the heap. Setting the pool size to 0 means than a new sparse counter will be allocated each time, just as standard Solr faceting works. * facet.sparse.stats=true adds a special tag with timing statistics for sparse faceting. * facet.sparse.stats.reset=true resets the timing statistics and clears the pool. The parameters needs to be given together with standard faceting parameters, such as facet=true&facet.field=myfield&facet.mincount=1&facet.sort=true. The defaults should be usable, so simply appending facet.sparse=true to the URL is a good start. 
Toke Eskildsen
made changes 
Description 
Field based faceting in Solr has two phases: Collecting counts for tags in facets and extracting the requested tags.
The execution time for the collecting phase is approximately linear to the number of hits and the number of references from hits to tags. This phase is not the focus here. The extraction time scales with the number of unique tags in the search result, but is also heavily influenced by the total number of unique tags in the facet as every counter, 0 or not, is visited by the extractor (at least for count order). For fields with millions of unique tag values this means 10s of milliseconds added to the minimum response time (see https://sbdevel.wordpress.com/2014/03/18/sparsefacetcountingonarealindex/ for a test on a corpus with 7M unique values in the facet). The extractor needs to visit every counter due to the current counter structure being a plain intarray of size #unique_tags. Switching to a sparse structure, where only the tag counters > 0 are visited, makes the extraction time linear to the number of unique tags in the result set. Unfortunately the number of unique tags in the result set is unknown at collect time, so it is not possible to reliably select sparse counting vs. full counting up front. Luckily there exists solutions for sparse sets that has the property of switching to nonsparsemode without a switchpenalty, when the sparsethreshold is exceeded (see http://programmingpraxis.com/2012/03/09/sparsesets/ for an example). This JIRA aims to implement this functionality in Solr (a proof of concept patch will be provided shortly). 
Field based faceting in Solr has two phases: Collecting counts for tags in facets and extracting the requested tags.
The execution time for the collecting phase is approximately linear to the number of hits and the number of references from hits to tags. This phase is not the focus here. The extraction time scales with the number of unique tags in the search result, but is also heavily influenced by the total number of unique tags in the facet as every counter, 0 or not, is visited by the extractor (at least for count order). For fields with millions of unique tag values this means 10s of milliseconds added to the minimum response time (see https://sbdevel.wordpress.com/2014/03/18/sparsefacetcountingonarealindex/ for a test on a corpus with 7M unique values in the facet). The extractor needs to visit every counter due to the current counter structure being a plain intarray of size #unique_tags. Switching to a sparse structure, where only the tag counters > 0 are visited, makes the extraction time linear to the number of unique tags in the result set. Unfortunately the number of unique tags in the result set is unknown at collect time, so it is not possible to reliably select sparse counting vs. full counting up front. Luckily there exists solutions for sparse sets that has the property of switching to nonsparsemode without a switchpenalty, when the sparsethreshold is exceeded (see http://programmingpraxis.com/2012/03/09/sparsesets/ for an example). This JIRA aims to implement this functionality in Solr. Current status: Sparse counting is implemented for field cache faceting, both single and multivalue, with and without docvalues. The patch applies cleanly to Solr 4.6.1 and should integrate well with everything as all functionality is unchanged. After patching, the following new parameters are possible: 
Toke Eskildsen
made changes 
Attachment  SOLR5894.patch [ 12637822 ]  
Attachment  SOLR5894_test.zip [ 12637823 ]  
Attachment  sparse_5000000docs_20140331151918_multi.png [ 12637824 ]  
Attachment  sparse_5000000docs_20140331151918_single.png [ 12637825 ] 
Toke Eskildsen
made changes 
Attachment  SOLR5894.patch [ 12637414 ]  
Attachment  sparse_50510000docs_20140328152807.png [ 12637415 ]  
Attachment  SOLR5894_test.zip [ 12637416 ] 
Toke Eskildsen
made changes 
Attachment  SOLR5894.patch [ 12637376 ]  
Attachment  SOLR5894_test.zip [ 12637377 ] 
Toke Eskildsen
made changes 
Attachment  SOLR5894.patch [ 12637139 ] 
Toke Eskildsen
made changes 
Attachment  author_7M_tags_1852_logged_queries_warmed.png [ 12636021 ] 
Toke Eskildsen
made changes 
Field  Original Value  New Value 

Attachment  SOLR5894.patch [ 12636012 ] 
Toke Eskildsen
created issue 