You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when using counter_culture to fix counts, all read operations (including counting records) happen on the primary database. This can cause significant lock contentions and performance issues, especially when running counter_culture_fix_counts in background jobs with large datasets.
Current Workaround
We currently have to explicitly specify using read replicas for each counter_culture_fix_counts call:
Problem
Currently, when using counter_culture to fix counts, all read operations (including counting records) happen on the primary database. This can cause significant lock contentions and performance issues, especially when running counter_culture_fix_counts in background jobs with large datasets.
Current Workaround
We currently have to explicitly specify using read replicas for each counter_culture_fix_counts call:
I was thinking something along these lines
Apologies for asking if this feature already exists
The text was updated successfully, but these errors were encountered: