There's a part of the code that performs UPDATE queries, but during load testing, I don't want these updates to actually change the state of the database. However, I still want the database to experience the full impact of the update — query planning, locking, I/O, WAL writes, etc. — so I can measure how it affects performance under peak load.
Is there a best-practice approach to achieve this?
So far, the most viable option I’ve found is to wrap the UPDATE queries in a transaction and then roll it back — that way, the queries still execute, but the state doesn’t change. Is this the right way to go? Does rollback introduce any performance overhead that would skew my results? Are there better or more realistic alternatives that simulate the full write path without persisting changes?
Thanks in advance!
sargstuff•11mo ago
very old school approach:
Misuse sql VIEW[3][4] to generate a temporary parallel table setup. Testing database separate from production database would be 'better', IMHO.
-----
[0] pgreplay-go : https://github.com/gocardless/pgreplay-go
[1] python locust : https://miguel-codes.medium.com/unconventional-load-testing-...
[2] pgbench load testing :
----------------------------[3] : a) https://hashrocket.com/blog/posts/materialized-view-strategi...
[4] : https://en.wikipedia.org/wiki/View_(SQL)LawZiL•11mo ago