[
https://issues.apache.org/jira/browse/SOLR-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12495222
]
Yonik Seeley commented on SOLR-221:
-----------------------------------
> it might be worth trying to clarify if the performance cliff really results
> from being *optimized* or if it's just a result of one of the two traits of
> an optimized index: being a single segment, having no deletions.
The large performance differences even when TermDocs weren't used (all
fieldcache) strongly suggests that it's a SegmentReader vs MultiReader issue
more than deleted docs, since I doubt the larger maxDoc would account for much
time. It would be nice to know for sure though.
> Minor point: if we're going to add facet config options, i'd prefer they stay
> as standard standard SolrParms
I think we may need to look at it on a per-option basis (but I agree, these
look like a candidate). Once 1.2 gets out the door, I'll probably get back to
my facet cache work, and that will have some parameters that *don't* make sense
to be able to tune per-request (or wouldn't even be possible).
> faceting memory and performance improvement
> -------------------------------------------
>
> Key: SOLR-221
> URL: https://issues.apache.org/jira/browse/SOLR-221
> Project: Solr
> Issue Type: Improvement
> Reporter: Yonik Seeley
> Assigned To: Yonik Seeley
> Attachments: facet.patch
>
>
> 1) compare minimum count currently needed to the term df and avoid
> unnecessary intersection count
> 2) set a minimum term df in order to use the filterCache, otherwise iterate
> over TermDocs
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
