From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Joe Conway <mail(at)joeconway(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: TRACE_SORT defined by default |
Date: | 2019-04-24 22:04:41 |
Message-ID: | 17893.1556143481@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> 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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-04-24 22:40:38 | Re: pg_dump is broken for partition tablespaces |
Previous Message | Peter Geoghegan | 2019-04-24 21:31:36 | Re: TRACE_SORT defined by default |