[
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
