Fix notification query plan for users with domain blocks #7981
No reviewers
Labels
No labels
AP C2S
AdminAPI
Breaking API
Breaks existing config
Check if still valid
Data Protection
Do not merge
Document in the changelog
Doing
Feature Request / Enhancement
MastoAPI
NL2
NL4
OStatus
OTP Releases
Refactor
Security
To Do
TwitterAPI
bug
complicated
confirmed
deps
discussion
documentation
easy
feature: to be merged in stable
fix: to be merged in stable
incident
needs to be backported to maint
needs-changes
needs-info
needs-review
performance
regression
unclear
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
pleroma/pleroma!7981
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/domain-block-subplan-cost"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
keep_following_or_not_domain_blocked/2uses? = ANY(SELECT ap_id FROM users JOIN following_relationships ...). Postgres folds that hashed sub-plan's startup cost into the actor index scan and charges it on every rescan of the nested loop, so for a user with a long follow list the index plan is estimated ~1000x too high and can lose to a plan that materialises every active user per candidate row.Wrapping the subselect in
ARRAY(...)makes it an InitPlan, evaluated and costed once.Measured on a 312 GB instance,
/api/v1/notificationsfor a user with 20k notifications and 2.3k follows:Adds a test for the followed-actor exception through
Notification.for_user/1.