TT-17841: improved tests for persistent storage - #158
Open
sredxny wants to merge 12 commits into
Open
probelabs / Visor: performance
succeeded
Aug 10, 2026 in 47s
✅ Check Passed (Warnings Found)
performance check passed. Found 1 warning, but fail_if condition was not met.
Details
📊 Summary
- Total Issues: 1
- Warning Issues: 1
🔍 Failure Condition Results
Passed Conditions
- global_fail_if: Condition passed
Issues by Category
Performance (1)
⚠️ persistent/internal/driver/postgres/basic_operations.go:366 - TheUpsertimplementation introduces a transaction-level advisory lock (pg_advisory_xact_lock) and an additionalCOUNTquery to ensure correctness under concurrency. This serializes concurrent upserts for the same logical record and adds a database round-trip to everyUpsertcall. While this is a valid trade-off for data integrity, it has a notable performance cost. Contention on the same logical record will result in serialization and reduced throughput, and the extraCOUNTquery adds latency to allUpsertoperations.
Powered by Visor from Probelabs
💡 TIP: You can chat with Visor using /visor ask <your question>
Annotations
Check warning on line 419 in persistent/internal/driver/postgres/basic_operations.go
probelabs / Visor: performance
performance Issue
The `Upsert` implementation introduces a transaction-level advisory lock (`pg_advisory_xact_lock`) and an additional `COUNT` query to ensure correctness under concurrency. This serializes concurrent upserts for the same logical record and adds a database round-trip to every `Upsert` call. While this is a valid trade-off for data integrity, it has a notable performance cost. Contention on the same logical record will result in serialization and reduced throughput, and the extra `COUNT` query adds latency to all `Upsert` operations.
Raw output
This change is a deliberate trade-off for correctness, as noted in the pull request description. For highly performance-critical paths, consider if a native `INSERT ... ON CONFLICT` statement could achieve the same goal with better performance, avoiding both the advisory lock and the extra `SELECT` query. This would likely require raw SQL or more advanced GORM features, potentially bypassing some of the existing abstractions. If the current performance is acceptable, this can be left as is, but the trade-off should be well-understood.
Loading