[
https://issues.apache.org/jira/browse/SOLR-13892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17016016#comment-17016016
]
Jason Gerlowski commented on SOLR-13892:
----------------------------------------
*Apologies* I incorrectly named my PR branch with capital letters and it looks
like it's been sending out commit notifications even though it's a feature
branch. Sorry if anyone got spammed by this. I'll fix it before any more work.
----
I created a Two-Phase Iterator implementation for comparison with the
postfilter implementation. They both exhibit the same performance
characteristics (see below). This was expected, since the main performance
gain here is in using top-level vs per-segment structures. With this proven
though I'm leaning more towards the TPI implementation.
!join-increasing-from-matches-tpi.png!
The main question is how we should expose this, alongside the existing
implementations. With a postfilter or TPI implementation added to the mix,
there's three main ways to run this qparser: normal (no score param), with a
"score" param, and "TopLevelJoin".
My vote would be to add a {{method}} param similar to what
{{TermsQParserPlugin}} offers. That allows users to choose their
implementation explicitly if desired, while keeping backcompat with the
existing parsing behavior. I'll make this change as I start to clean things
up. Don't feel strongly if anyone has other thoughts though.
> Add postfilter support to {!join} queries
> -----------------------------------------
>
> Key: SOLR-13892
> URL: https://issues.apache.org/jira/browse/SOLR-13892
> 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-13892.patch, SOLR-13892.patch,
> join-increasing-from-matches-tpi.png, join-increasing-from-matches1.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The JoinQParserPlugin would be a lot performant in many use-cases if it could
> operate as a post-filter, especially when doc-values for the involved fields
> are available.
> With this issue, I'd like to propose a post-filter implementation for the
> {{join}} qparser.
--
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
