Re: Multiple fq vs combined fq performance

All non-cached filters will be executed together (leapfrog between them) and will be sorted by the filter cost (I guess that, since you aren't setting a cost, then the order of the input matters). You can try setting a cost in your filters (lower than 100, so that they don't become post filters)

Re: Multiple fq vs combined fq performance

Thanks for the suggestion, Alex. It doesn't appear that IndexOrDocValuesQuery (at least in Solr 7.7.1) supports the PostFilter interface. I've tried various values for cost on each of the fq and it doesn't change the QTime. So, after digging around a bit even though

Re: Multiple fq vs combined fq performance

I _think_ it will run all 3 and then do index hopping. But if you know one fq is super expensive, you could assign it a cost Value over 100 will try to use PostFilter then and apply the query on top of results from other queries.

Multiple fq vs combined fq performance

Hi all! In a collection where we have ~54 million documents we've noticed running a query with the following: "fq":["{!cache=false}_class:taggedTickets", "{!cache=false}taggedTickets_ticketId:100241", "{!cache=false}companyId:22476"] when I debugQuery I see:

Re: fq performance

control in the same documents / resources itself or it's kept outside and they do join in the query. -- View this message in context: http://lucene.472066.n3.nabble.com/fq-performance-tp4325326p4340057.html Sent from the Solr - User mailing list archive at Nabble.com.

Re: fq performance

You may want to consider a join, esp. if you're ever consider thousands of groups. e.g. fq={!join from=access_control_group to=doc_group}access_control_user_id:USERID On 18 March 2017 at 05:57, Yonik Seeley wrote: > On Fri, Mar 17, 2017 at 2:17 PM, Shawn Heisey

Re: fq performance

On Fri, Mar 17, 2017 at 2:17 PM, Shawn Heisey wrote: > On 3/17/2017 8:11 AM, Yonik Seeley wrote: >> For Solr 6.4, we've managed to circumvent this for filter queries and >> other contexts where scoring isn't needed. >> http://yonik.com/solr-6-4/ "More efficient filter

Re: fq performance

On 3/17/2017 8:11 AM, Yonik Seeley wrote: > For Solr 6.4, we've managed to circumvent this for filter queries and > other contexts where scoring isn't needed. > http://yonik.com/solr-6-4/ "More efficient filter queries" Nice! If the filter looks like the following (because q.op=AND), does it

Re: fq performance

And to chime in. bq: It contains information about who have access to the documents, like field as (U1_s:true). I wanted to make explicit the implications of Micael's response. You are talking about different _fields_ per user or group, i.e. Don't do this, it's horribly wasteful. Instead as

Re: fq performance

On Fri, Mar 17, 2017 at 9:09 AM, Shawn Heisey wrote: [...] > Lucene has a global configuration called "maxBooleanClauses" which > defaults to 1024. For Solr 6.4, we've managed to circumvent this for filter queries and other contexts where scoring isn't needed.

Re: fq performance

On 3/17/2017 12:46 AM, Ganesh M wrote: > For how many ORs solr can give the results in less than one second.Can > I pass 100's of OR condtion in the solr query? will that affects the > performance ? This is a question that's impossible to answer. The number will vary depending on the nature of

Re: fq performance

Hi Ganesh, you might want to use something like this: fq=access_control:(g1 g2 g5 g99 ...) Then it's only one fq filter per request. Internally it's like an OR condition, but in a more condensed form. I already have used this with up to 500 values without larger performance degradation (but

Re: fq performance

Hi Shawn / Michael, Thanks for your replies and I guess you have got my scenarios exactly right. Initially my document contains information about who have access to the documents, like field as (U1_s:true). if 100 users can access a document, we will have 100 such fields for each user. So when

Re: fq performance

On 3/16/2017 6:02 AM, Ganesh M wrote: > We have 1 million of documents and would like to query with multiple fq > values. > > We have kept the access_control ( multi value field ) which holds information > about for which group that document is accessible. > > Now to get the list of all the

Re: fq performance

First of all, from what I can see, this won't do what you're expecting. Multiple fq conditions are always combined using AND, so if a user is member of 100 groups, but the document is accessible to only 99 of them, then the user won't find it. Or in other words, if you add a user to some

fq performance

Hi, We have 1 million of documents and would like to query with multiple fq values. We have kept the access_control ( multi value field ) which holds information about for which group that document is accessible. Now to get the list of all the documents of an user, we would like to pass