Tom Lane wrote: > Kevin Brown <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]