Re: TRACE_SORT defined by default

On Wed, Apr 24, 2019 at 2:15 PM Joe Conway <mail(at)joeconway(dot)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. In
any case the current status quo is that it's built by default. I have
used it in production, though not very often. It's easy to turn it on
and off.

> Maybe the answer to both is "yes", but if so I would agree that we ought
> to remove the define and ifdef's and just bake it in.

We're only talking about removing the option of including the
instrumentation in binaries when Postgres is built. I'm not aware that
anyone is doing that. It nobody was doing that, then nobody could be
affected by removing the #ifdef crud.

I suspect that the reason that this hasn't happened already is because
it leaves trace_sort/TRACE_SORT in the slightly awkward position of no
longer quite meeting the traditional definition of a "developer
option".

--
Peter Geoghegan