[
https://issues.apache.org/jira/browse/SOLR-13890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17009194#comment-17009194
]
Mikhail Khludnev edited comment on SOLR-13890 at 1/6/20 10:08 PM:
------------------------------------------------------------------
regarding {{PerSegmentViewDocIdSetIterator}}: I don't follow. Lucene's
{{DocIdSetIterator}} is strictly per-segment, using it for top-level iteration
is something that never happen. fwiw, usually toplevel Solr docsets converted
to Lucene's DocIdSets via {{DocSet.getTopFilter()}}.
adding argument to method {{QueryMethod.makeFilter(String fname, BytesRef[]
bytesRefs, SolrParams localParams)}} is not something which is backward
compatible, and might frustrate other devs.
Note: {{TopLevelDocValuesTermsQuery}} uses {{OrdinalMap}} via
{{getSlowAtomicReader()}}. It might be clearer to iterate persegment, and then
access global ordinals via MultiSortedDocValues.mapping.getGlobalOrds()
Also, this query relies on SolrIndexSearcher, but iirc even in Solr queries
sometimes invoked with Lucene's Searcher. There's some issues with such cast.
was (Author: mkhludnev):
regarding {{PerSegmentViewDocIdSetIterator}}: I don't follow. Lucene's
{{DocIdSetIterator}} is strictly per-segment, using it for top-level iteration
is something that never happen. fwiw, usually toplevel Solr docsets converted
to Lucene's DocIdSets via {{DocSet.getTopFilter()}}.
adding argument to method {{QueryMethod.makeFilter(String fname, BytesRef[]
bytesRefs, SolrParams localParams)}} is not something which is backward
compatible, and might frustrate other devs.
Note: {{TopLevelDocValuesTermsQuery}} uses {{OrdinalMap}} via
{{getSlowAtomicReader()}}. It might be clearer to iterate persegment, and then
access global ordinals via MultiSortedDocValues.mapping.getGlobalOrds()
> Add postfilter support to {!terms} queries
> ------------------------------------------
>
> Key: SOLR-13890
> URL: https://issues.apache.org/jira/browse/SOLR-13890
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: query parsers
> Affects Versions: master (9.0)
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Major
> Attachments: SOLR-13890.patch, SOLR-13890.patch, SOLR-13890.patch,
> SOLR-13890.patch, SOLR-13890.patch, SOLR-13890.patch, Screen Shot 2020-01-02
> at 2.25.12 PM.png, post_optimize_performance.png,
> toplevel-tpi-perf-comparison.png
>
>
> There are some use-cases where it'd be nice if the "terms" qparser created a
> query that could be run as a postfilter. Particularly, when users are
> checking for hundreds or thousands of terms, a postfilter implementation can
> be more performant than the standard processing.
> WIth this issue, I'd like to propose a post-filter implementation for the
> {{docValuesTermsFilter}} "method". Postfilter creation can use a
> SortedSetDocValues object to populate a DV bitset with the "terms" being
> checked for. Each document run through the post-filter can look at their
> doc-values for the field in question and check them efficiently against the
> constructed bitset.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
