[
https://issues.apache.org/jira/browse/LUCENE-3500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13123521#comment-13123521
]
Robert Muir commented on LUCENE-3500:
-------------------------------------
{quote}
Not a tight loop perhaps, but I've regularly seen fast changing indexes build
up to 100 segments.
{quote}
So in this fast changing case doesn't it make more sense for solr to cache the
filters without deleted docs and not do the extra liveDocs check?
{quote}
but it's more about the chipping away at inefficiencies.
{quote}
well i think it makes some assumptions dependent upon the current
implementation?
Deleted docs are written to the index and like other things ideally codec could
customize the impl in the future.
thats the only problem i have with it.
separately: we call this a lot less since LUCENE-3474 patch. Previously if you
had a BQ of 100 terms, it would call it 100 times per segment.
now we call it once per segment in that case.
> improve getLiveDocs() performance
> ---------------------------------
>
> Key: LUCENE-3500
> URL: https://issues.apache.org/jira/browse/LUCENE-3500
> Project: Lucene - Java
> Issue Type: Improvement
> Reporter: Yonik Seeley
> Priority: Minor
> Attachments: LUCENE-3500.patch
>
>
> On segmentReader, liveDocs is volatile because they used to be loaded on
> demand.
> This no longer appears to be the case... liveDocs are always loaded up front.
> This also means that getLiveDocs() can never fail (even after close), and we
> can remove the ensureOpen call.
> Minor optimizations, but volatile reads still do prevent optimizations across
> that boundary.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
