Tom Lane wrote:
> Kevin Brown <kevin@sysexperts.com> writes:
> > 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.
>
>
> > 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.
>
> In other words, more than an eighty percent penalty on simple commands.
> Not negligible in my book.
Guess that's true when looked at that way. :-)
Then again, that's the worst possible case: a simple command that only
invokes the parser and executor, doesn't reference any tables, doesn't
call any functions, and doesn't even write to anything. As a
percentage of the work actually done on real systems, how often are
such commands executed?
In any case, it *does* show that there is a very high penalty for the
option relative to the operations that should be much more complex,
like parsing the command. Why in the world is the penalty so high? I
thought it would be a simple matter of copying the command to an
element of a structure that's overlaid onto a bit of shared memory
allocated to the backend process for its statistics. In short, a
simple memory to memory copy, with perhaps the acquisition of a write
lock on the structure. I'd expect such an operation to take a few
microseconds at most (especially on the kind of hardware I was testing
on), but it's orders of magnitude worse. I have trouble believing
that the locking protocols required for this operation are that
inefficient unless we're doing something drastically wrong on that
front, and it's almost impossible for me to believe that the simple
operation of copying data to a shared memory segment would be that
inefficient.
--
Kevin Brown kevin@sysexperts.com
