Tom Lane wrote:
> Kevin Brown <kevin@sysexperts.com> writes:
> > Would it make more sense to enable stats_command_string by default?
>
> I'd vote against it. If we turn it on by default, people are paying
> for a feature they may not even know exists. Once they find out about
> it and decide they want it, they can turn it on easily enough.
>
> If you can show that the overhead is unmeasurable, that'd indicate that
> this argument is bogus; but I suspect it's not negligible, at least on
> simple queries.
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.
The difference in time over 100000 passes was 20 seconds (44 seconds
with stats_command_string turned on, 24 with it turned off), for an
impact of 0.2 milliseconds per command executed. This was on a 1.5GHz
P4 with 1G of RAM running Linux 2.4.20 on ReiserFS. The data is
stored on a software RAID-5 across 3 Seagate ST-380021A IDE drives,
each connected to a separate channel on a Promise ATA100 card.
I have no idea if that's small enough to be considered negligible or
not, considering the hardware it was running on.
--
Kevin Brown kevin@sysexperts.com