Hi,
Query 1: select META().id from books USE INDEX (books_one USING FTS) where _class = 'com.org.One’ and any f in field4 satisfies f = ‘abc’ end
Query 2: select META().id from books USE INDEX (books_one USING FTS) where _class = 'com.org.One’ and any f in field4 satisfies f IN [‘abc’, ‘def’] end
Query 1 works okay but query 2 fails. How to fix query 2?
@vsr1 's correct. With 6.6, we interpret several N1QL functionality into FTS but all of it. Interpreting IN into FTS will be supported from 7.0. Until then you’d need use OR.
Hi @abhinav ,
If we need to use OR clause for replacement of IN, then how many data will be supported in OR clause? I mean how many ORs we can use for better performance? Is there any limit?
OR clauses never helps to to better your query performance, the more the number of OR clauses - the lower the query performance as the search has to cover more area of the index/indexed items.
There is a configurable limit on 1024 sub clauses in a disjunct or OR clauses internally, but this is overridable. Again the internal number of eventual search clauses depends on the type of queries like regex/wildcards/prefix fuzzy etc as each of these query types internally becomes a fan out operations of all possible candidate terms matching the query.
So, in that case, till the time IN clause is not supported in FTS, i can’t use FTS. We have heavy use of IN clause with 1000s of data in the list which don’t have any specific pattern.
Can you suggest anything better performant thing here?
Note: Everything will be term query with keyword analyzer on the field on that IN clause. Data is identifier kind of thing. Hope, this will help you to give me better performant solution instead of using OR clause.
The first recommendation is that - revisit the queries or data retrieval path if possible. Can you make the searches for finer scopes/target data sets with precise identifiers?
Having thousands of search clauses means - there is no exclusivity of target data. The more clauses/entries or search requirements you add irrespective of the internal implementation, you essentially search for more items, and hence it has its performance cost implications.
Even when we support IN clause from N1QL /Flex query, the internal implementations could be based on Disjuncts/OR queries.
If you can add a few MUST match fields along with the OR clauses, then it would help improve the performance.
You could try a conjunct query with all MUST match fields and a single sub-clause as a disjunct one with all the OR clauses.