Open ceyhunsen opened 3 days ago
PostgreSQL transactions appears to be hygienic.
Another important property of transactional databases is closely related to the notion of atomic updates: when multiple transactions are running concurrently, each one should not be able to see the incomplete changes made by others.
https://www.postgresql.org/docs/current/tutorial-transactions.html
Meaning example change is OK.
Also, select statements takes a snapshot before executing query and search for values in that snapshot, regardless using a transaction or not.
In effect, a SELECT query sees a snapshot of the database as of the instant the query begins to run. However, SELECT does see the effects of previous updates executed within its own transaction, even though they are not yet committed. Also note that two successive SELECT commands can see different data, even though they are within a single transaction, if other transactions commit changes after the first SELECT starts and before the second SELECT starts.
https://www.postgresql.org/docs/current/transaction-iso.html#XACT-READ-COMMITTED
Proposal Description
Research if database transactions are prone to multi threaded read/write operations. If not, refactor some parts of the code to not use transaction to gain some performance. Example: https://github.com/chainwayxyz/clementine/pull/309/commits/786d1b45fc15abc880c567f94b1e069ce2e5bee5