I think that in your example Postgres spends most time on waiting for
fsync() to complete. On Linux, for a battery-backed raid controller,
it's safe to mount ext4 filesystem with "barrier=0" option which
improves fsync() performance a lot. I have partitions mounted with this
option and I did a test from Python, using psycopg2 driver, and I got
the following latencies, in milliseconds:
- INSERT without COMMIT: 0.04
- INSERT with COMMIT: 0.12
- SELECT: 0.05
I'm also repeating benchmark runs multiple times (I'm using Python's
"timeit" module).
On 03/27/2015 07:58 PM, Ben Bromhead wrote:
Latency can be so variable even when testing things locally. I quickly
fired up postgres and did the following with psql:
ben=# CREATE TABLE foo(i int, j text, PRIMARY KEY(i));
CREATE TABLE
ben=# \timing
Timing is on.
ben=# INSERT INTO foo VALUES(2, 'yay');
INSERT 0 1
Time: 1.162 ms
ben=# INSERT INTO foo VALUES(3, 'yay');
INSERT 0 1
Time: 1.108 ms
I then fired up a local copy of Cassandra (2.0.12)
cqlsh> CREATE KEYSPACE foo WITH replication = { 'class' :
'SimpleStrategy', 'replication_factor' : 1 };
cqlsh> USE foo;
cqlsh:foo> CREATE TABLE foo(i int PRIMARY KEY, j text);
cqlsh:foo> TRACING ON;
Now tracing requests.
cqlsh:foo> INSERT INTO foo (i, j) VALUES (1, 'yay');
