On Mon, Apr 11, 2016 at 2:54 PM, Robert Haas wrote:
> I'm not excited about this change. It doesn't really buy us anything
> that I can see. For one thing, I think we've arguably got too much
> trace_sort output from sorts now and should look to reduce that
> instead of further normalizing it.
On Mon, Apr 11, 2016 at 4:43 PM, Peter Geoghegan wrote:
> Currently, debug instrumentation for sorting is only available if the
> TRACE_SORT macro was defined when PostgreSQL was compiled. It is
> defined by default, and so in practice it's always available; there is
> really no upside to disablin
On Mon, Apr 11, 2016 at 2:35 PM, Simon Riggs wrote:
> Yeh, sort has changed enough now that fixes weren't going to backpatch
> cleanly, so its a good time to do cleanup.
I wonder if the category of "Developer Options" is appropriate for
trace_sort. trace_sort is closer to log_executor_stats, whic
On 11 April 2016 at 21:43, Peter Geoghegan wrote:
> Currently, debug instrumentation for sorting is only available if the
> TRACE_SORT macro was defined when PostgreSQL was compiled. It is
> defined by default, and so in practice it's always available; there is
> really no upside to disabling it.
Currently, debug instrumentation for sorting is only available if the
TRACE_SORT macro was defined when PostgreSQL was compiled. It is
defined by default, and so in practice it's always available; there is
really no upside to disabling it. "18.17. Developer Options" notes
this restriction for trace
