-
Notifications
You must be signed in to change notification settings - Fork 157
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
Search with reverse chaining performing slowly #1705
Labels
Comments
I saw similar when we merged the initial PR for this feature: #1666 (comment) |
lmsurpre
added a commit
that referenced
this issue
Nov 13, 2020
The `R.LOGICAL_RESOURCE_ID = LR.LOGICAL_RESOURCE_ID` part of this join is unnecessary because R.RESOURCE_ID is the unique identifier on the Resources (R) table...so if LR.CURRENT_RESOURCE_ID = R.RESOURCE_ID then this RESOURCES row will always have a LOGICAL_RESOURCE_ID which matches the LOGICAL_RESOURCES row. Making this change changed the processing results of the following query from over 5 minutes down to under 1 second on my postgresql db with ~30,000 patients and ~300,000 conditions: `GET [base]/Patient?_has:Condition:patient:code=http://snomed.info/sct|44054006` Signed-off-by: Lee Surprenant <lmsurpre@us.ibm.com>
lmsurpre
added a commit
that referenced
this issue
Nov 13, 2020
issue #1705 - simplified top-level join avoids bad postgresql plan for simple _has queries
Running this search today with the latest code loaded on my local FHIR server linked to the large postgres DB. this is now taking about 3.6 seconds to complete. |
Closing based on Dag's comment. Future enhancements can come as a result of #677 findings / fixes. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
A clear and concise description of what the bug is.
The following search with _has takes over 2 minutes to run in the large postgres DB.
[base]/Patient?_has:Observation:patient:code-value-quantity=http://loinc.org|2339-0$68.6
To Reproduce
Steps to reproduce the behavior:
Expected behavior
A clear and concise description of what you expected to happen.
The search should return faster than 2 minutes. in most deploys it would timeout.
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: