This repository was archived by the owner on Dec 13, 2023. It is now read-only.
Replies: 1 comment
-
|
Hi |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Recently we divided main workflow into subworkflows. As soon as this changes in deployed production following query taking long time and consuming 100% of cpu on db.
SELECT message_id, priority, payload FROM queue_message WHERE queue_name = $1 AND popped = ? AND deliver_on <= (current_timestamp + (? ||?)::interval)
ORDER BY priority DESC, deliver_on, created_on LIMIT $2 FOR UPDATE SKIP LOCKED"
Db is postgres,
queue implementation postgres
conducton : 3.13.2
As it is prod issue, we have to figure out how to reduce this. is throwing more capacity only the option now?
Beta Was this translation helpful? Give feedback.
All reactions