-
Notifications
You must be signed in to change notification settings - Fork 73
Open
Description
Problem
The current implementation has a single mutex per connection (OwnedPostgresConnection::connection_lock), meaning only ONE query can execute at a time per attached PostgreSQL database. This is a bottleneck for:
- Concurrent queries from multiple threads
- Federated query systems that execute multiple queries in parallel
- Data virtualization platforms
Proposed Solution
We've implemented and tested two improvements:
1. Connection Pool (postgres_connection_pool.hpp/cpp)
A thread-safe connection pool that maintains multiple connections to the same PostgreSQL database.
- Configurable min/max pool size
- Connection health checks
- Automatic cleanup of idle connections
- Thread-safe borrowing/returning with condition variables
- RAII wrapper for automatic connection return
2. Query Result Cache (postgres_query_cache.hpp/cpp)
An LRU cache for identical query results to avoid repeated round-trips.
- Configurable max entries and memory limit
- TTL-based expiration
- LRU eviction policy
- Thread-safe operations
Performance Impact
We tested in a production data virtualization system:
| Scenario | Before | After | Improvement |
|---|---|---|---|
| 10 concurrent queries | 1993ms | 192ms | 10x faster |
| Repeated identical queries | 162ms | <1ms | 160x faster |
| Simple queries | 352ms | 145ms | 2.4x faster |
Implementation
Full implementation available at: https://github.com/6th-Element-Labs/ActionEngine/tree/stratum/postgres_scanner
Key files:
src/include/postgres_connection_pool.hppsrc/postgres_connection_pool.cppsrc/include/postgres_query_cache.hppsrc/postgres_query_cache.cpp
Backward Compatibility
These changes are fully backward compatible:
- New classes are additive, existing code unchanged
- Pool and cache are opt-in features
- Default behavior remains single-connection
Would the maintainers be interested in a PR with these improvements?
Metadata
Metadata
Assignees
Labels
No labels