[
https://issues.apache.org/jira/browse/SOLR-13892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17012945#comment-17012945
]
Jason Gerlowski commented on SOLR-13892:
----------------------------------------
Revisiting this after some time away. I've moved the code to a PR here:
https://github.com/apache/lucene-solr/pull/1159. I've found this confusing on
some jiras, so to be explicit: *all patches on this jira predate the PR and are
out of date*.
The main (albeit, temporary) addition to the PR at this point is a performance
test driver I threw together to show a use-case where the top-level DV approach
shines performance-wise. The performance test mimics a common setup for doing
document-level authorization: a "user_acls" collection has users and the groups
they belong to, and a "products" collection has product records with a field
representing the groups that record is visible to.
The performance test stages the "user_acls" data with 100 users (user1, user2
...user100): each belonging to an increasing number of groups. This lets us
show one advantage of the top-level DV approach: it scales much better with the
number of "from" matches.
!join-increasing-from-matches1.png!
The takeaway here isn't that the top-level approach is better or worse than
existing approaches. This perf test is only one specific use case after all.
But it's pretty clear that it serves some use-cases better and it's worth
getting in.
Next steps for this jira are:
* consider Two-Phase Iterator instead of postfilter. (I'm not sure TPI makes
as much sense here as it did on SOLR-13890, but still thinking through some of
the lessons learned there.)
* cleanup
* clarify (unify?) ref-guide coverage on different joins, and when each
can/should be used.
> 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-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: [email protected]
For additional commands, e-mail: [email protected]