Tom Lane wrote: > Kevin Brown <[EMAIL PROTECTED]> writes: > > 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. > > > > 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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly