Re: [HACKERS] psql - add special variable to reflect the last querystatus
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] psql - add special variable to reflect the last querystatus |
Дата | |
Msg-id | alpine.DEB.2.20.1709072148300.3598@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] psql - add special variable to reflect the last query status (Pavel Stehule <pavel.stehule@gmail.com>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: