This repository has been 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
-
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