[
https://issues.apache.org/jira/browse/SOLR-13892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968123#comment-16968123
]
Mikhail Khludnev commented on SOLR-13892:
-----------------------------------------
[~jbernste], Thanks for your comments.
{quote}The postfilter in this patch is not the main optimization{quote}
OK. Fair. It might make sense to highlight it into the issue summary. So, far
it doesn't meet user expectation about post filtering: when I have
{{fq=id:1&fq={!foo cost=9000}...}} I expect that post filter just checks one
doc with {{id:1}}, which is not the case here since {{PostFilterJoinQuery}}
materializes {{toOrdBitSet}}. And there are probably shorter way to yield
bitset as a filter for standard intersection algorithm.
{quote}Notice the bytesrefs from the to index are sorted without sorting.{quote}
Sure. They are sorted/merged in {{SlowCompositeReaderWrapper}} and
{{OrdinalMap}} and hopefully cached until searcher is thrown away by commit.
{quote}Also notice that in the patch the bytesrefs from the from index are
never materialized in memory at once{quote}
I'd say: They are materialized already in memory at least once in
{{SlowCompositeReaderWrapper}} and {{OrdinalMap}}, but the point is correct.
Concurrently running joins doesn't duplicate those ByteRefs, which seems to be
happen with JoinUtils.
{quote}This can be slow when there are a large number of join terms because
seeks into the terms enum need to be done for the entire join list for each
segment{quote}
Note: the case for {{{!join score=none}}} is highly selective "from"-side
query, and frequently updated index with tradeoff in query time caused by
segment enumeration. In 400K wide scan usecase you mention above, classic join
might run relatively well too.
So, I think this feature can be proposed for users purposing peak throughput on
static indices. I suggest to name it referring to 'global ordinals' at least to
avoid clashing with real post filter aka existential join LUCENE-6332.
> 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
> Priority: Major
> Attachments: SOLR-13892.patch
>
>
> 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
