Kevin Brown <kevin@sysexperts.com> writes:
> It's not unmeasurable, but it is reasonably low (guess it depends on
> your definition of "reasonable" :-). I wrote a small perl script
> which would do a "SELECT 1" in a loop as many times as I specified on
> the command line (autocommit was turned off). I measured the amount
> of wall clock time it took to do 100000 passes on an unloaded system
> with stats_command_string enabled, and then the same thing with it
> disabled.
FWIW, I did a comparable test using a slightly more reasonable example
(ie, a query that does useful work): in the regression database,PREPARE q(int) AS SELECT * FROM tenk1 WHERE unique1 =
$1
followed by 10000 executions ofEXECUTE q(42)
This was with autocommit on (ie, each EXECUTE is its own transaction)
and using a C-coded client (a small tweak of src/test/examples/testlibpq.c).
Averaging over three trials on an unloaded system, I got 21.0 seconds
with stats_command_string off, 27.7 with it on, or about 32% overhead.
My conclusion is that stats_command_string overhead is non-negligible
for simple commands. So I stand by my previous opinion that it should
not be turned on without the DBA taking explicit action to turn it on.
Do you want it on in every future benchmark, for example?
regards, tom lane
