-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
fix: Performance and high memory usage of relation hint calculation #4472
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -70,3 +70,23 @@ def test_should_not_fail_with_stack_overflow(defaultenv): | |
| assert response.status_code == 404 | ||
| data = response.json() | ||
| assert data["code"] == "PGRST205" | ||
|
|
||
|
|
||
| def test_second_request_for_non_existent_table_should_be_quick(defaultenv): | ||
| "requesting a non-existent relationship should be quick after the fuzzy search index is loaded (2nd request)" | ||
|
|
||
| env = { | ||
| **defaultenv, | ||
| "PGRST_DB_SCHEMAS": "fuzzysearch", | ||
| "PGRST_DB_POOL": "2", | ||
| "PGRST_DB_ANON_ROLE": "postgrest_test_anonymous", | ||
| } | ||
|
|
||
| with run(env=env, wait_max_seconds=30) as postgrest: | ||
| response = postgrest.session.get("/unknown-table") | ||
| assert response.status_code == 404 | ||
| data = response.json() | ||
| assert data["code"] == "PGRST205" | ||
| first_duration = response.elapsed.total_seconds() | ||
| response = postgrest.session.get("/unknown-table") | ||
| assert response.elapsed.total_seconds() < first_duration / 10 | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This test is flaky and fails often both locally and in CI which is not desirable. If the point is to prove that the second request is always faster, I think we should remove the
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
That looks enough to remove the flakiness. @mkleczek WDYT?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I would experiment with different dividers so that we test that the second request is really faster. I guess 2 might be safe (on my machine 20 was working fine, made it to 10 but it seems it might be lower still). OTOH I am wondering if this test is really needed since we have load tests to measure error response scenarios.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
It is a regression test so it is good to keep this test. The test proves and also in a way documents that we build a fuzzy set on the very first request and so that request is slower than the following requests which are "much" faster.
Seems good to me. 👍 |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was just going to release v14 then realized this changelog entry was put in the wrong spot, messing up our
postgrest-releasecommand.This was already fixed on #4589, but please be mindful of the CHANGELOG placement @mkleczek 🙏