[
https://issues.apache.org/jira/browse/SOLR-13890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16988831#comment-16988831
]
David Smiley commented on SOLR-13890:
-------------------------------------
I think PostFilterDocValuesTermsQuery needs to justify it's existence in a
javadoc. Such a javadoc should acknowledge that DVTQ has a TwoPhaseIterator
and acknowledge it's similarity to a PostFilter (if you continue with your
PostFilter approach, otherwise it's irrelevant).
The likely explanation for a performance improvement is top-level vs
per-segment algorithm. I _highly doubt_ the PostFilter abstraction somehow
offers a perf benefit in your benchmark that cannot be achieved with
TwoPhaseIterator. You could benchmark/test this easily by simply doing a
segment optimize (forceMerge) and seeing if the performance suddenly becomes
the same. This is because a single segment scenario makes the two algorithmic
choices equivalent. To do such a top-level algorithm with TwoPhaseIterator,
you'd override createWeight and resolve the top level ordinals up front there.
Lucene has no query logs. It'd be nice if query explain emitted wether it uses
TPI but it does not. I'm not arguing against users having the ability to
_force_ TPI if they choose; that's quite doable.
> 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
>
>
> 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
