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
We recently had a performance regression caused by a bug introduced in a postgres query (see #5207 for more details). In retrospect we could have caught this issue in code review if the query plan was checked before merging the PR with the problematic query. We could have also caught this issue if we thoroughly tested the claimable balances endpoint on the staging environment. It would be nice to have a way to systematically detect these DB query regressions before they get released.
Maybe something like: persist the expected query plan for all queries, that way the PR diff will always include changes in query plan (even if the change comes from a table/view schema change). There is bit of a wrinkle that for this to be the most effective we'd need a good sample database state so that we would catch issues like the one you're fixing here (scans too large need to be obvious), but this may not be too much of a problem (we can create tables filled with mostly junk?).
The text was updated successfully, but these errors were encountered:
We recently had a performance regression caused by a bug introduced in a postgres query (see #5207 for more details). In retrospect we could have caught this issue in code review if the query plan was checked before merging the PR with the problematic query. We could have also caught this issue if we thoroughly tested the claimable balances endpoint on the staging environment. It would be nice to have a way to systematically detect these DB query regressions before they get released.
One idea suggested by @MonsieurNicolas :
The text was updated successfully, but these errors were encountered: