[
https://issues.apache.org/jira/browse/LUCENE-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739541#action_12739541
]
Mark Miller commented on LUCENE-1771:
-------------------------------------
bq. Hmm... shouldn't explain take the top-level Searcher (not IndexSearcher)?
Yeah, I can switch it - I only changed it to that to match the ability to get
numDocs (by getting the IndexReader). If we fix that issue though, we don't
need that and it can go back to Searcher.
{quote}Maybe instead we should simply throw an exception if
QueryWeight.explain(IndexReader, int) is called, stating that the Query impl
must instead implement the new explain (that takes the top-level Searcher)?
Would that be safer than risking accidental 2X mem usage due to a custom
Query's explain?{quote}
And break back compat?! Yeah, that seems reasonable to me. Anyone else?
> Using explain may double ram reqs for fieldcaches when using
> ValueSourceQuery/CustomScoreQuery or for ConstantScoreQuerys that use a
> caching Filter.
> ----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-1771
> URL: https://issues.apache.org/jira/browse/LUCENE-1771
> Project: Lucene - Java
> Issue Type: Bug
> Components: Search
> Reporter: Mark Miller
> Assignee: Mark Miller
> Fix For: 2.9
>
> Attachments: LUCENE-1771.patch, LUCENE-1771.patch, LUCENE-1771.patch,
> LUCENE-1771.patch
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
