-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance drop on excessive number of IN() set conditions. #62
Comments
I've debugged for this query, and I've ended up again I couldn't benchmarked in depth though, I don't know if it slowed down another query, but as far as I saw this workaround solved my performance issues on wide in() conditions for now. For this reason I didn't created a PR for this, because I don't know if it is a solution or not: |
Hi, have you able to look through this issue? We have splitted our queries because of this issue, big queries and small ones. if we send big queries to reindexer, it will become unresponsive soon. |
Hello, @oruchreis. We've been quite busy developing other issues and didn't have any chance to take a look at your problem - we are quite sorry about that. I've just dubbed this issue in our local repository (we use gitlab) and we're going to fix it in the nearest future. Sorry for all the inconveniences and thank you for your patience. |
Hi @oruchreis. We have investigated issue.
|
Hi,
I'm using Reindexer a few months without any performance issues. And I'm quite happy with query performance especially for queries that have IN(set) conditions. But lately, some namespaces growed more in these months, and I'm facing some performance issues on specific queries on big namespaces which have items about 1 million. I've figured out if the count of values in the set condition is smaller from a limit it executes
index
method, if it is bigger then this limit, it executesscan
method which is very slow. And I think this limit is changing by items count in the namespace.I've uploaded dump file of the namespace to reproduce this issue. For this specific namespace, If the set condition has 679 values, it executes
index
method, but if the count of values is 680 then it executesscan
method which results slower query. Also I've figured out if it executesscan
method, the current activities page in the face displays asselect_loop
which takes about 30-50sn. And if the count of thisscan
queries increased over time, then cpu usage are also increasing exponentially.I've tested on v2.6.2, 2.9.1, 2.11.0, 2.11.1 and 3.0.0 on both linux and windows.
Here is the dump of namespace to reproduce the issue:
TestNs.zip
And the query which executes
scan
method instead ofindex
method. It executedscan
in v3.0.0 and prior versions but if it doesn't executescan
method you can increase amount of values in theIN
condition.The text was updated successfully, but these errors were encountered: