Hello Pavel,
I checked performance - the most fast queries are execution of simple
prepared statement
prepare x as select 1;
-- 1000000 x
execute x;
execute x;
execute x;
execute x;
## patched
[pavel@nemesis postgresql]$ time psql -At -1 postgres -f ~/xxx.sql >
/dev/null
real 0m44,887s
user 0m11,703s
sys 0m6,942s
This is probably the most worst case, what is possible and see some
slowdown - in this case there is about 10% slowdown -
but it is pretty untypical - the one query was less than 50 microsec. When
there will be any IO activity or network usage, than this patch doesn't
create any significant overhead.
Interesting. Thanks for the test.
I tried to replicate with a variant without any output: "SELECT;"
SELECT NOW() AS start \gset
BEGIN;
SELECT; -- 2^19 times
END;
SELECT NOW() - :'start';
The run time is about 19 µs per SELECT on my laptop. Over 33 runs each
alternating master with and without the patch, I got the following stats
on the measured time in seconds (average, stddev [min Q1 median Q3 max]):
- with : 9.898 ± 0.158 [9.564, 9.762, 9.936, 10.037, 10.108]
- without: 9.419 ± 0.294 [8.670, 9.226, 9.533, 9.625, 9.845]
This seems consistent and significant. It suggests a 0.40-0.50 s
difference, that is about 5%, i.e. about (under) 1 µs overhead per
statement in pretty defavorable circumstances.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
