Re: stats_command_string default?

From: Kevin Brown <kevin(at)sysexperts(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: stats_command_string default?
Date: 2003-02-17 03:54:07
Message-ID: 20030217035407.GL1833@filer
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:
> Kevin Brown <kevin(at)sysexperts(dot)com> writes:
> > Tom Lane wrote:
> >> Kevin Brown <kevin(at)sysexperts(dot)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(at)sysexperts(dot)com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Brown 2003-02-17 03:55:49 Re: location of the configuration files
Previous Message mlw 2003-02-17 03:41:37 Re: location of the configuration files

Browse pgsql-patches by date

  From Date Subject
Next Message Christopher Kings-Lynne 2003-02-17 05:26:23 Non-colliding auto generated names
Previous Message Tom Lane 2003-02-17 02:30:06 Re: stats_command_string default?