On Fri, 26 Apr 2019 at 05:49, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote:
>
> On Wed, Apr 24, 2019 at 06:04:41PM -0400, Tom Lane wrote:
> >Peter Geoghegan <pg@bowt.ie> writes:
> >> On Wed, Apr 24, 2019 at 2:15 PM Joe Conway <mail@joeconway.com> wrote:
> >>> Has anyone ever (or recently) measured the impact on performance to have
> >>> this enabled? Is it that generically useful for debugging of production
> >>> instances of Postgres that we really want it always enabled despite the
> >>> performance impact?
> >
> >> It is disabled by default, in the sense that the trace_sort GUC
> >> defaults to off. I believe that the overhead of building in the
> >> instrumentation without enabling it is indistinguishable from zero.
> >
> >It would probably be useful to actually prove that rather than just
> >assuming it. I do see some code under the symbol that is executed
> >even when !trace_sort, and in any case Andres keeps complaining that
> >even always-taken branches are expensive ...
> >
>
> Did I hear the magical word "benchmark" over here?
>
> I suppose it'd be useful to have some actual numbers showing what
> overhead this actually has, and whether disabling it would make any
> difference. I can't run anything right away, but I could get us some
> numbers in a couple of days, assuming there is some agreement on which
> cases we need to test.
If you're worried about overheads of dtrace-style probes, you can
(with systemtap ones like we use) generate a set of semaphores as a
separate .so that you link into the final build. Then you can test for
TRACE_POSTGRESQL_FOO_BAR_ENABLED() and only do any work required to
generate input for the trace call if that returns true. You can
generally unlikely() it since you don't care about the cost of it with
tracing enabled nearly as much.
--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise