5 ms·
I don't get the transaction bit. At least with postgres, a transaction doesn't guarantee that all statements in it see the data at the same point in time (actua
by Spixel_ 1y ago
I don't get the transaction bit. At least with postgres, a transaction doesn't guarantee that all statements in it see the data at the same point in time (actually, it's not even guaranteed for subqueries).
Also, often, the transactional database servers is more difficult to scale than application servers so from a technical standpoint, it makes sense to do this glue work in app code.
- TheTaytay 1y agoDoesn’t it guarantee consistency from the time the transaction started (assuming read committed isolation)? It guarantees you won’t see something “later” than when your transaction began. https://www.postgresql.org/docs/current/transaction-iso.html https://www.postgresql.org/docs/current/transaction-iso.html I’m likely misunderstanding what you mean by time.
- Spixel_ 1y agoRead committed (which is the default), doesn't guarantee that. See "Nonrepeatable Read" and "Phantom Read" which are both possible in your documentation page.
- andyferris 1y ago> a transaction doesn't guarantee that all statements in it see the data at the same point in time This depends on the transaction isolation level. If you use snapshot or serializable this should be the case (but you may have aborted transactions due to optimistic concurrency).
- Spixel_ 1y agoYou are right, but note that the default isolation level is "Read committed" in postgres.
- Jweb_Guru 1y agoSSI scales fine for most workloads as long as you correctly mark your read-only transactions.