[ https://issues.apache.org/jira/browse/SOLR-6331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14088349#comment-14088349 ]
Hoss Man commented on SOLR-6331: -------------------------------- This spun out of an idea i originally floated in SOLR-2894, but didn't move forward on because it will involve quite a bit of refactoring... {quote} * the way refinement currently works in PivotFacetField, after we've refined our values, we mark that we no longer need refinement, and then on the next call we recursively refine the subpivots of each value – and in both cases we do the offset+limit calculations and hang on to all of the values (both below offset and above limit) as we keep iterating down hte pivots – they don't get thrown away until the final trim() call just before building up the final result. * i previously suggested folding the trim() logic into the NamedList response logic – but now i'm wondering if the trim() logic should instead be folded into refinement? so once we're sure a level is fully refined, we go ahead and trim that level before drilling down and refining it's kids? {quote} > possible memory optimization for distributed pivot faceting > ----------------------------------------------------------- > > Key: SOLR-6331 > URL: https://issues.apache.org/jira/browse/SOLR-6331 > Project: Solr > Issue Type: Improvement > Reporter: Hoss Man > > As noted in a comment in {{PivotFacetField.trim()}}... > {code} > // we can probably optimize the memory usage by trimming each level of the > pivot once > // we know we've fully refined the values at that level > // (ie: fold this logic into refineNextLevelOfFacets) > {code} -- This message was sent by Atlassian JIRA (v6.2#6252) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org