This repository has been archived by the owner on Mar 11, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 86
SQL causing 100% CPU usage on stage (not seen on prod yet, stage has more data) #2210
Labels
Comments
but the LEFT JOIN iterations "iter" ON "work_items"."fields" @> concat('{"system.iteration": "', iter.id, '"}')::jsonb should ensure that only one area is joined to each work item, shouldn't it? |
@kwk @aslakknutsen if this affects OSIO, can you create a bug on openshifio and link to this. |
4 tasks
|
kwk
added a commit
that referenced
this issue
Aug 7, 2018
This includes an extra-condition in the `ON` part of the table `JOINS` for areas, codebases and iterations to only join those tables filtered by their space ID. I'm not sure though if this really fixes the problem (see #2210 (comment)). ## TODO As of yesterday's (07.08.2018) discussion with @aslakknutsen we did experiments and found that in order to keep the rows in the search small, we have to establish a condition on the final SQL `WHERE` clause that limits the selection to work items from a particular space. At the moment, the current `/api/search` endpoint is so generic that it doesn't require a limitation by space on the root of the `WHERE` clause. That's why @aslakknutsen and I agreed to create a search endpoint under `/api/spaces/<SPACE-UUID>/search` in order to automatically add the space ID to the query condition. This will be implemented in another PR and is tracked in openshiftio/openshift.io#4124 See #2210.
kwk
added a commit
to openshiftio/saas-openshiftio
that referenced
this issue
Aug 7, 2018
commit fabric8-services/fabric8-wit@2661cf8 Author: Konrad Kleine <[email protected]> Date: Tue Aug 7 15:40:55 2018 +0200 Provide join lock down (fabric8-services/fabric8-wit#2211) This includes an extra-condition in the `ON` part of the table `JOINS` for areas, codebases and iterations to only join those tables filtered by their space ID. I'm not sure though if this really fixes the problem (see fabric8-services/fabric8-wit#2210 (comment)). ## TODO As of yesterday's (07.08.2018) discussion with @aslakknutsen we did experiments and found that in order to keep the rows in the search small, we have to establish a condition on the final SQL `WHERE` clause that limits the selection to work items from a particular space. At the moment, the current `/api/search` endpoint is so generic that it doesn't require a limitation by space on the root of the `WHERE` clause. That's why @aslakknutsen and I agreed to create a search endpoint under `/api/spaces/<SPACE-UUID>/search` in order to automatically add the space ID to the query condition. This will be implemented in another PR and is tracked in openshiftio/openshift.io#4124 See fabric8-services/fabric8-wit#2210.
aslakknutsen
pushed a commit
to openshiftio/saas-openshiftio
that referenced
this issue
Aug 7, 2018
commit fabric8-services/fabric8-wit@2661cf8 Author: Konrad Kleine <[email protected]> Date: Tue Aug 7 15:40:55 2018 +0200 Provide join lock down (fabric8-services/fabric8-wit#2211) This includes an extra-condition in the `ON` part of the table `JOINS` for areas, codebases and iterations to only join those tables filtered by their space ID. I'm not sure though if this really fixes the problem (see fabric8-services/fabric8-wit#2210 (comment)). ## TODO As of yesterday's (07.08.2018) discussion with @aslakknutsen we did experiments and found that in order to keep the rows in the search small, we have to establish a condition on the final SQL `WHERE` clause that limits the selection to work items from a particular space. At the moment, the current `/api/search` endpoint is so generic that it doesn't require a limitation by space on the root of the `WHERE` clause. That's why @aslakknutsen and I agreed to create a search endpoint under `/api/spaces/<SPACE-UUID>/search` in order to automatically add the space ID to the query condition. This will be implemented in another PR and is tracked in openshiftio/openshift.io#4124 See fabric8-services/fabric8-wit#2210.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This ends up in a full table scan of iterations and loop over each iteration against the workitems table etc. 57000*124000
This basically never returns.
If you add a
it returns in 0.7ms.
The text was updated successfully, but these errors were encountered: