Instead of doing everything on inform (which isn't great for NRT), we should just do it on-demand in the comparator in setNextReader() for only those uniqueKeys that were boosted)

We could cache the uniqueKey -> docid across queries, but not sure it's worth it at this point (assuming at most a handful of docs are boosted per-query). And if we did want some sort of uniqueKey -> docid cache it would make most sense to be an internal cache in SolrIndexSearcher, not private to the QEC.

It would probably be most performant to do the lookup perSegment (i.e. in setNextReader) and remove documents as they are found (i.e. if the doc exists in segment1, don't bother looking it up in further segments). This will also mean that we only do hash lookups in the SentinelIntSet when there actually exists a boosted doc in the segment.

First draft. This just does the mapping in the constructor to the comparator. We could do setNextReader, but I can't imagine it will really make much difference given the small number of items that we typically would expect to be elevated.

Note, I'm going to try the way Yonik suggested too, but wanted to put this up as a first draft.

Also, I need to double check my comparator understanding b/c perhaps the doc ids are off due to getting a top level reader.

I can't imagine it will really make much difference given the small number of items that we typically would expect to be elevated.

The fact that it will be a small number of elevated docs is entirely my point - that means that if we do it per segment, that there will normally be no documents elevated in a specific segment and the hash lookup can be skipped (and that would be a sizeable gain for something simple like a term query). You're right about small sets - it doesn't matter if the set size is 1 or 10 if you do need to do the lookup.

This patch moves the work to setNextReader

Minor cleanup. I think this is ready to go and will likely commit later today or tomorrow.

OK, just had a chance to view the comparator part of this patch.

Here's a patch that fixes

• minor check-for-null for fields() and terms() which can return null
• even though docsEnum returns something, it may be deleted (i.e. need to check for NO_MORE_DOCS)
• use liveDocs when requesting the docsEnum so we won't use a deleted (overwritten) doc.

The last two issues would both cause us to miss elevated documents if they have been updated and an old deleted version still exists in the index.

+1, go ahead and commit.