On Fri, 26 Apr 2019 at 05:49, Tomas Vondra wrote:
>
> On Wed, Apr 24, 2019 at 06:04:41PM -0400, Tom Lane wrote:
> >Peter Geoghegan writes:
> >> On Wed, Apr 24, 2019 at 2:15 PM Joe Conway wrote:
> >>> Has anyone ever (or recently) measured the impact on performance to have
> >>> this enabled? Is
On Thu, 25 Apr 2019 at 06:41, Peter Geoghegan wrote:
>
> On Wed, Apr 24, 2019 at 3:04 PM Tom Lane 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 indisti
On Wed, Apr 24, 2019 at 06:04:41PM -0400, Tom Lane wrote:
Peter Geoghegan writes:
On Wed, Apr 24, 2019 at 2:15 PM Joe Conway 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 Pos
On Thu, Apr 25, 2019 at 1:56 PM Tom Lane wrote:
> Well, I was suggesting that we ought to consider the alternative of
> making it *not* always compiled, and Jeff was pushing back on that.
Right. Sorry.
--
Peter Geoghegan
Alvaro Herrera writes:
> On 2019-Apr-25, Jeff Janes wrote:
>> I've had people use it to get some insight into the operation and memory
>> usage of Aggregate nodes, since those nodes offer nothing useful via
>> EXPLAIN ANALYZE. It would be a shame to lose that ability on
>> package-installed Postg
On Thu, Apr 25, 2019 at 1:52 PM Alvaro Herrera wrote:
> But the proposal is not to remove the _code_. The proposal is just to
> remove that "#ifdef" lines that would make it conditionally compilable,
> *if* the symbol that they test weren't always enabled. In other words,
> turn it from "always
On 2019-Apr-25, Jeff Janes wrote:
> I've had people use it to get some insight into the operation and memory
> usage of Aggregate nodes, since those nodes offer nothing useful via
> EXPLAIN ANALYZE. It would be a shame to lose that ability on
> package-installed PostgreSQL unless we fix Aggregate
On Wed, Apr 24, 2019 at 6:04 PM Tom Lane wrote:
> Peter Geoghegan writes:
>
> > 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?
>
On Wed, Apr 24, 2019 at 3:04 PM Tom Lane 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 actuall
Peter Geoghegan writes:
> On Wed, Apr 24, 2019 at 2:15 PM Joe Conway 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
On Wed, Apr 24, 2019 at 2:29 PM Alvaro Herrera wrote:
> This is a really strange argument. You're saying that somebody thought
> about it: "Hmm, well, I can remove this preprocessor symbol but then
> trace_sort would no longer resemble a developer option. So I'm going to
> leave the symbol alone
On 2019-Apr-24, Peter Geoghegan wrote:
> I suspect that the reason that this hasn't happened already is because
> it leaves trace_sort/TRACE_SORT in the slightly awkward position of no
> longer quite meeting the traditional definition of a "developer
> option".
This is a really strange argument.
On Wed, Apr 24, 2019 at 2:15 PM Joe Conway 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
On 4/24/19 5:10 PM, Peter Geoghegan wrote:
> On Wed, Apr 24, 2019 at 2:07 PM Joe Conway 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 #ifd
On Wed, Apr 24, 2019 at 2:07 PM Joe Conway 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 t
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.
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development
signature.a
16 matches
Mail list logo
