Re: TRACE_SORT defined by default
От | Tomas Vondra |
---|---|
Тема | Re: TRACE_SORT defined by default |
Дата | |
Msg-id | 20190425214909.xfh4vchyo3zsygzz@development обсуждение исходный текст |
Ответ на | Re: TRACE_SORT defined by default (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: TRACE_SORT defined by default
|
Список | 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 по дате отправления: