Konstantin>I have obtained more results with YCSB benchmark and built-in connection pooling
Could you provide more information on the benchmark setup you have used?
For instance: benchmark library versions, PostgreSQL client version, additional/default benchmark parameters.
Konstantin>Postgres shows significant slow down with increasing number of connections in case of conflicting updates.
Konstantin>Built-in connection pooling can somehow eliminate this problem
Can you please clarify how connection pooling eliminates slow down?
Is the case as follows?
1) The application updates multiple of rows in a single transaction
2) There are multiple concurrent threads
3) The threads update the same rows at the same time
If that is the case, then the actual workload is different each time you vary connection pool size.
For instance, if you use 1 thread, then the writes become uncontended.
Of course, you might use just it as a "black box" workload, however I wonder if that kind of workload ever appears in a real-life applications. I would expect for the applications to update the same row multiple times, however I would expect the app is doing subsequent updates, not the concurrent ones.
On the other hand, as you vary the pool size, the workload varies as well (the resulting database contents is different), so it looks like comparing apples to oranges.
Vladimir