-
Notifications
You must be signed in to change notification settings - Fork 1
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
Basic collection-membership query can be very slow #92
Comments
Even after a |
Would an index on 'score' and 'modified' help? https://www.postgresql.org/docs/8.3/static/indexes-ordering.html |
|
I think the basic problem here might be the 50M+ extraneous rows in |
fifty million is not an especially big number |
Sure, if they're intraneous. If they're extraneous, it's a big number. |
yes, but the point is — querying that table at that size shouldn't be nearly as expensive an operation as it is; tidying up the collections masks, but doesn't solve, the problem with this issue. |
Actual query executed by the Spindle module for Quilt:
Notably, this actually returns an empty set (because nothing is a member of
cbe0cdeca6b340b19ed57d7290fcceaf
), but takes some time to do it. A query only on themembership
table returns instantly, suggesting that the query planner is performing the join in a non-optimal order.We should investigate how best to hint to the planner that the collection-membership constraint is one which has a low cost and high benefit in terms of filtering rows from the joined tables.
Note that reversing the join order doesn't appear to make a material difference to query performance.
Related to #72.
Possibly the cause of some of the issues ascribed to #87.
Internal tracking: RESDATA-1093
The text was updated successfully, but these errors were encountered: