[
https://issues.apache.org/jira/browse/SOLR-13890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17007714#comment-17007714
]
David Smiley commented on SOLR-13890:
-------------------------------------
I could pick apart lots of statements made but I choose these:
bq. I'm still thinking about the postfilter vs TPI question. The downside of
continuing with postfilter is low, since Solr has a handful of others already
and no one has shown interest in removing them.
I have an interest in removing them, albeit slowly. I've already removed a
spatial one on a feature branch related to spatial deprecations generally
(there's an existing issue); targeting 9.0. FuntionRangeQuery is one on my
mind, and I have a patch in progress.
bq. And there's a bit of an advantage to doing postfilter here too: in that it
lets users pick between top-level and per-segment logic as they'd like without
requiring any additional params.
What the parameters and their defaults is entirely up to us right here.
bq. Eliminating the postfilter means, in my opinion overloading the behavior of
traditional filters to have to deal intelligently with caches, or asking the
user to dive into the details of caching.
What do you mean by "traditional filters"? If you mean "fq", then to be clear
I'm totally accepting of having the queries auto-default cache=false depending
on whatever. There are trade-offs but I'm good with having defaults that are
more optimal for more users, even if that may make it harder to reason about
what that default is. This is orthogonal to TPI vs PostFilter or per-segment
vs top-level.
In a nutshell, PostFilter was once the only way to "post filter" but has become
entirely redundant (correct me if I'm wrong on that). Even if someone likes
this interface and likes its documentation, it nonetheless exists in a large
search stack where there is already a solution, and is thus extra cognitive
overhead (complexity) to think about and to maintain in Solr itself
(SolrIndexSearcher has to know about it).
> 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, Screen Shot 2020-01-02 at 2.25.12 PM.png,
> post_optimize_performance.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
