-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Fix for count being very slow on large Parse Classes' collections (Postgres) #5330
Fix for count being very slow on large Parse Classes' collections (Postgres) #5330
Conversation
…esnt work for us/
…plex query specified
…Postgres. Replicating fix for Mongo in issue 5264
Codecov Report
@@ Coverage Diff @@
## master #5330 +/- ##
==========================================
- Coverage 93.96% 93.95% -0.01%
==========================================
Files 123 124 +1
Lines 9027 9056 +29
==========================================
+ Hits 8482 8509 +27
- Misses 545 547 +2
Continue to review full report at Codecov.
|
That’s a great idea. Seems that a few PG tests broke along the way. Can you have a look? Sent with GitHawk |
Thoughts on the broken tests? 7740.3:
I believe the reason this fails is because the postgres database is freshly created and hasn't had a chance to have the pg_class table built... since this is an estimate and not an exact value. Unsure of how 7740.5 relates to count. |
@CoderickLamar we can disable this test on PG specifically if we need to (look for Sent with GitHawk |
@flovilmart, we've disabled the tests for PG as suggested but we're getting new errors which don't seem to be related to the previous ones. I was wondering if you could point us in the right direction by any chance? Thanks.
|
Usually, when a test hit the timeout, it’s because Sent with GitHawk |
@CoderickLamar I looked this over real quick.
Based on the wiki you posted, the estimate value updates on certain events. If you would have ran I think as a fall back looking at the failing test.
|
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.
Just a few nits from me
Thanks for your reply. @dplewis I have made the changes requested. As for the errors which still persist, on my local they are passing fine and they're not taking long either: Do we need to increase the timeout? |
Perhaps a different Postgres version? Sent with GitHawk |
What version are running I tried it on 9.6 and 10 and it works for me locally |
Travis runs 9.5 Sent with GitHawk |
@flovilmart I’ll try 9.5 but I don’t know how this would affect the schema. I’ll try tomorrow |
@flovilmart @dplewis I was running PG 11 on my local. |
@dplewis @flovilmart How can we get postgres updated on travis? |
We should not, instead the fix should be compatible with Postgres 9.5. Sent with GitHawk |
On that note, we should figure out the best route forward. We should get this test passing, but it sounds like that is separate task? |
The tests that are failing on this branch are passing on the master branch. So the changes introduce a possible regression. Sent with GitHawk |
Also, excluding the tests is not something I am a big fan of, as we should maintain the same level of features on all databases Sent with GitHawk |
@CoderickLamar As I mentioned above #5330 (comment) estimate count will always be 0 until it is updated by an event. I was able to get the failing test to work locally somehow.
Same goes for This means things like deleting from schema needs a hard count or somewhat close estimation . |
@behrangs Thank you for the fix. Simple and beautiful. Can you resolve the conflicts? There is a dependency bot that handles updating packages |
What are the next steps here? |
@CoderickLamar @ben-sab Can you try this branch with your projects? I don't know how long autovacuum takes on your machines for you to see an estimated count thats not zero. |
Everything is looking good on my end. Speedy dashboard once again. |
Can we get this merged into a release? |
How often are releases usually put together on master? |
…stgres) (parse-community#5330) * Changed count to be approximate. Should help with postgres slowness * refactored last commit to only fall back to estimate if no complex query * handlign variables correctly * Trying again because it was casting to lowercase table names which doesnt work for us/ * syntax error * Adding quotations to pg query * hopefully final pg fix * Postgres will now use an approximate count unless there is a more complex query specified * handling edge case * Fix for count being very slow on large Parse Classes' collections in Postgres. Replicating fix for Mongo in issue 5264 * Fixed silly spelling error resulting from copying over notes * Lint fixes * limiting results to 1 on approximation * suppress test that we can no longer run for postgres * removed tests from Postgres that no longer apply * made changes requested by dplewis * fixed count errors * updated package.json * removed test exclude for pg * removed object types from method * test disabled for postgres * returned type * add estimate count test * fix mongo test
Fetching the count for Postgres tables that are large, >5 mil in our case, takes an extremely long time that bogs down the server. This is a known issue with Postgres: https://wiki.postgresql.org/wiki/Slow_Counting
If no complex query is supplied, this will now default to estimating the count which is accurate enough for parse dashboard.
This is an equivalent fix to commit 5264 which solved this for MongoDb.