Re: TRACE_SORT defined by default - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: TRACE_SORT defined by default
Date
Msg-id 20190425214909.xfh4vchyo3zsygzz@development
Whole thread Raw
In response to Re: TRACE_SORT defined by default  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: TRACE_SORT defined by default
List pgsql-hackers
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.


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services 



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Why is it OK for dbsize.c to look at relation files directly?
Next
From: Andres Freund
Date:
Subject: Re: REINDEX INDEX results in a crash for an index of pg_class since9.6