4 ms·

If you want performance to completely tank, sure.

• hipadev23 3y ago
  Afaik, it only locks the row(s) in question. Do you have a setup where the same row is being updated by multiple clients all the time?
  • jtc331 3y ago
    SELECT FOR UPDATE means two queries can’t _read_ the same row at the same time, right?
    • hipadev23 3y ago
      To my understanding, yes. If you have broad select queries across all the rows, that would slow things down quite a bit.
      • dilyevsky 3y ago
        You can use SKIP LOCKED normally. That’s how popular queue implementations usually work. I believe pg even calls this out in their docs
  • quickthrower2 3y ago
    SQL Server will escalate locks. Because keeping a million rows locked is expensive.
  • dig1 3y ago
    This can easily happen if you have multiple services that can write/update in the same table/rows and rely on database coordination instead of using an external queue like Kafka. Postgres (presumably other databases) can propagate these locks to table locks [1] and cause contention for the whole infra. [1] https://blog.heroku.com/curious-case-table-locking-update-query https://blog.heroku.com/curious-case-table-locking-update-qu...