Improve comment in triggers.sql (#4789)

* Clarified existing info
* Added prohibition of inconsistent update order

crates/db_schema/replaceable_schema/triggers.sql

@@ -5,12 +5,17 @@
 -- (even if only other columns are updated) because triggers can run after the deletion of referenced rows and
 -- before the automatic deletion of the row that references it. This is not a problem for insert or delete.
 --
--- After a row update begins, a concurrent update on the same row can't begin until the whole
--- transaction that contains the first update is finished. To reduce this locking, statements in
--- triggers should be ordered based on the likelihood of concurrent writers. For example, updating
--- site_aggregates should be done last because the same row is updated for all local stuff. If
--- it were not last, then the locking period for concurrent writers would extend to include the
--- time consumed by statements that come after.
+-- Triggers that update multiple tables should use this order: person_aggregates, comment_aggregates,
+-- post_aggregates, community_aggregates, site_aggregates
+--   * The order matters because the updated rows are locked until the end of the transaction, and statements
+--     in a trigger don't use separate transactions. This means that updates closer to the beginning cause
+--     longer locks because the duration of each update extends the durations of the locks caused by previous
+--     updates. Long locks are worse on rows that have more concurrent transactions trying to update them. The
+--     listed order starts with tables that are less likely to have such rows.
+--     https://www.postgresql.org/docs/16/transaction-iso.html#XACT-READ-COMMITTED
+--   * Using the same order in every trigger matters because a deadlock is possible if multiple transactions
+--     update the same rows in a different order.
+--     https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-DEADLOCKS
 --
 --
 -- Create triggers for both post and comments