From df7e4b54de91cca6dd415489c32cf7eb68336f8a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jos=C3=A9=20Alberto=20Leiva=20Obando?= Date: Tue, 17 Oct 2023 11:43:06 -0600 Subject: [PATCH] Update postgres-SSI-performance-testing.md --- .../postgres-SSI-performance-testing.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/docs/performance-testing/postgres-SSI-performance-testing.md b/docs/performance-testing/postgres-SSI-performance-testing.md index 41d16e20..46617111 100644 --- a/docs/performance-testing/postgres-SSI-performance-testing.md +++ b/docs/performance-testing/postgres-SSI-performance-testing.md @@ -55,3 +55,10 @@ These results are consistent with the Autocannon results: - SSI version has less commits than previous version, and more rollbacks than previous version, that makes sense because we are not locking the database and we are executing a rollback to retry. - Also, SSI version returned more tuples but affected tuples are less compared to previous version. That behavior is consistent with a retry mechanism, because when we need to retry, we need to restart the process. + +## Conclusion +- The version with SSI reduces latency but also generates a large amount of rollback, so the number of altered records is smaller. + +- Additionally, in cases like locking\delete.test.ts, removing the SELECT...FOR UPDATE/SHARE can cause errors and deadlocks. + +- For SSI to be effective, retry logic must be implemented, otherwise many transactions would fail without altering any records. \ No newline at end of file