[ 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