On Wed, Apr 24, 2019 at 06:04:41PM -0400, Tom Lane wrote:
Peter Geoghegan <p...@bowt.ie> writes:
On Wed, Apr 24, 2019 at 2:15 PM Joe Conway <m...@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.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
