lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (Commented) (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3500) improve getLiveDocs() performance
Date Sat, 08 Oct 2011 15:30:30 GMT


Robert Muir commented on LUCENE-3500:

Not a tight loop perhaps, but I've regularly seen fast changing indexes build up to 100 segments.

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?

but it's more about the chipping away at inefficiencies. 

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:
>             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:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message