On Wed, Apr 24, 2019 at 3:04 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > 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.
The number of individual trace_sort LOG messages is proportionate to
the number of runs produced.
> 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 ...
I think that you're referring to the stuff needed for the D-Trace
probes. It's a pity that there isn't better support for that, since
Linux has a lot for options around static userspace probes these days
(SystemTap is very much out of favor, and never was very popular).
There seems to be a recognition among the Linux people that the
distinction between users and backend experts is blurred. The kernel
support for things like eBPF and BCC is still patchy, but that will
change.
> Would any non-wizard really have a use for it?
That depends on what the cut-off point is for wizard. I recognize that
there is a need to draw the line somewhere. I suspect that a fair
number of people could intuit problems in a real-world scenario using
trace_sort, without having any grounding in the theory, and without
much knowledge of tuplesort.c specifically.
> 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.
The information that it makes available is approximately the same as
the information made available by the new
pg_stat_progress_create_index view, but with getrusage() stats.
--
Peter Geoghegan
