Re: Built-in connection pooling

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

>