Re: TRACE_SORT defined by default

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: TRACE_SORT defined by default
Дата
Msg-id 17893.1556143481@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: TRACE_SORT defined by default  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: TRACE_SORT defined by default  (Peter Geoghegan <pg@bowt.ie>)
Re: TRACE_SORT defined by default  (Jeff Janes <jeff.janes@gmail.com>)
Re: TRACE_SORT defined by default  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
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 ...

> 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.

Would any non-wizard really have a use for it?

It seems like we should either make this really a developer option
(and hence not enabled by default) or else move it into some other
category than DEVELOPER_OPTIONS.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: TRACE_SORT defined by default
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: pg_dump is broken for partition tablespaces