Re: stats_command_string default?

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