| From: | Joe Conway <mail(at)joeconway(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | 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 21:15:25 |
| Message-ID: | 5734f077-0ce4-09a6-43e4-87ffb3f75e1b@joeconway.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 4/24/19 5:10 PM, Peter Geoghegan wrote:
> On Wed, Apr 24, 2019 at 2:07 PM Joe Conway <mail(at)joeconway(dot)com> wrote:
>> I just noticed that TRACE_SORT is defined by default (since 2005
>> apparently). It seems odd since it is the only debugging code enabled by
>> default.
>
> I think that we should get rid of the #ifdef stuff, so that it isn't
> possible to disable the trace_sort instrumentation my commenting out
> the TRACE_SORT entry in pg_config_manual.h. I recall being opposed on
> this point by Robert Haas. Possibly because he just didn't want to
> deal with it at the time.
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?
Maybe the answer to both is "yes", but if so I would agree that we ought
to remove the define and ifdef's and just bake it in.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2019-04-24 21:23:31 | Re: TRACE_SORT defined by default |
| Previous Message | Peter Geoghegan | 2019-04-24 21:10:44 | Re: TRACE_SORT defined by default |