From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: unexpected psql "feature" |
Date: | 2016-07-14 08:21:07 |
Message-ID: | alpine.DEB.2.20.1607141007420.1962@sto |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Consider a throttled read-only load composed of 3 random selects,
> several rounds (so.sql) vs one (so2.sql):
>
> > pgbench -h server -T 100 -P 1 --rate 200 -c 2 -f so.sql -f so2.sql
> SQL script 1: so.sql
> - latency average = 1.878 ms
> SQL script 2: so2.sql
> - latency average = 1.089 ms
>
> There is 0.8 ms latency reduction, that is a 40% difference. Standard
> deviation is also significantly lower.
More fun with these two scripts, for those who focus on tps.
> pgbench -h server -M prepared -T 10 -P 1 -c 8 -f so.sql
...
latency average = 1.128 ms
latency stddev = 0.167 ms
tps = 7024.818252 (including connections establishing)
> pgbench -h server -T 10 -P 1 -c 8 -f so2.sql
# cannot do "-M prepared" on multiple commands... anyway:
...
latency average = 0.454 ms
latency stddev = 0.110 ms
tps = 17317.807554 (including connections establishing)
A mere 2.46 speedup for the read-only load.
The same with a "simple update" pgbench load, not compound & prepared:
latency average = 1.716 ms
latency stddev = 1.890 ms
tps = 4623.270608 (including connections establishing)
vs compound but not prepared:
latency average = 1.294 ms
latency stddev = 0.870 ms
tps = 6122.289249 (including connections establishing)
Ok, it is less impressive, just 30% better.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2016-07-14 08:21:14 | Re: Issue in pg_catalog.pg_indexes view definition |
Previous Message | Amit Langote | 2016-07-14 08:15:46 | Re: Issue in pg_catalog.pg_indexes view definition |