Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork9.7k
DB table locks on messenger_messages with many failures#52276
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
bn-jdcook commentedOct 24, 2023
I am not sure why AppVeyor is failing but it appears to be on all PRs to 5.4. |
…ssages with many failures
fabpot commentedOct 25, 2023
Thank you@bn-jdcook. |
antonkomarev commentedOct 25, 2023 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
@bn-jdcook how does this affect performance? Doesn't the database query planner care about the order of WHERE clauses? What database are you using? Have you tried to make EXPLAIN to see if the query plan is different? // I'm not against these changes. Order is more logical now. But I haven't faced such issues in Postgres. |
ghost commentedOct 25, 2023
I agree a reporter should mention a database he's using when reporting an issue related to the database. Btw. I really wonder whether a database can create a query plan that knows which AND condition to use first (unless both columns do not differ somehow from database point of view). E.g. how can it know that filtering first by |
Uh oh!
There was an error while loading.Please reload this page.
This reorders the query to target the
queue_namefirst and not include anyfailedmessages in the first part of theWHEREclause to help performance.