Re: unexpected psql "feature" - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: unexpected psql "feature"
Date
Msg-id alpine.DEB.2.20.1607141007420.1962@sto
Whole thread Raw
In response to Re: unexpected psql "feature"  (Fabien COELHO <coelho@cri.ensmp.fr>)
List 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.



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: Issue in pg_catalog.pg_indexes view definition
Next
From: Dilip Kumar
Date:
Subject: Re: Issue in pg_catalog.pg_indexes view definition