Re: Built-in connection pooling - Mailing list pgsql-hackers

From Vladimir Sitnikov
Subject Re: Built-in connection pooling
Date
Msg-id CAB=Je-G3S7O69nmsxFdsFRLi9dFFb5Jyrv7Xg-dgR5A0__3fQg@mail.gmail.com
Whole thread Raw
In response to Re: Built-in connection pooling  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Responses Re: Built-in connection pooling  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
List pgsql-hackers
Konstantin>I have not built YCSB myself, use existed installation.

Which pgjdbc version was in use?

Konstantin>One of the main problems of Postgres is significant degrade of performance in case of concurrent write access by multiple transactions to the same sows.

I would consider that a workload "problem" rather than PostgreSQL problem.
That is, if an application (e.g. YCSB) is trying to update the same rows in multiple transactions concurrently, then the outcome of such updates is likely to be unpredictable. Does it make sense?

At least, I do not see why Mongo would degrade in a different way there. Oleg's charts suggest that Mongo does not degrade there, so I wonder if we compare apples to apples in the first place. 

Vladimir

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: proposal: alternative psql commands quit and exit
Next
From: Bruce Momjian
Date:
Subject: Re: proposal: alternative psql commands quit and exit