Hello Alik,

Your description is not very precise. What version of Postgres is used? If there is a decline, compared to which version? Is there a link to these results?

Benchmark have been done in master v10. I am attaching image with results:
.

Ok, thanks.

More precision would be helpful, such as the exact pgbench option used (eg how many client per thread in pgbench, how long does it run, prepared transactions, ...).

Intuitively, contention should explain a saturation of the tps performance, because more clients are not effective to improve tps as the wait for other clients, and the latency would degrade.

But it is unclear to me why the tps would be reduced even with lock contention, so something seems amiss.

Performance debugging by mail is an uneasy task.

Maybe you could try zipf with unlogged tables, to check whether skipping the WAL write does something.

Also Amit advice about the perf report looks useful.

Given the explanations, the random draw mostly hits values at the beginning of the interval, so when the number of client goes higher one just get locking contention on the updated row?

Yes, exactly.

Ok. The uniform distribution run, if all other parameters are equal, gives a hint about the potential performance when the performance bottleneck is hit.

On Workload A with uniform distribution PostgreSQL shows better results than MongoDB and MySQL(see attachment). Also you can notice that for small number of clients type of distribution does not affect on tps on MySQL.

Ok. I assume that you use pgbench for pg and other ad-hoc tools for the other targets (mysql & mongodb).

--
Fabien.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to