Re: Unimpressed with pg_attribute_always_inline - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Unimpressed with pg_attribute_always_inline
Date
Msg-id 20959.1515456728@sss.pgh.pa.us
Whole thread Raw
In response to Re: Unimpressed with pg_attribute_always_inline  (Andres Freund <andres@anarazel.de>)
Responses Re: Unimpressed with pg_attribute_always_inline
Re: Unimpressed with pg_attribute_always_inline
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> Unless this pg_attribute_always_inline gets a lot more widely
> proliferated I don't see a need to change anything. Debuggability isn't
> meaningfully impacted by seing more runtime attributed to
> ExecHashJoin/ExecParallelHashJoin rather than ExecHashJoinImpl.

When I complained that always_inline inhibits debuggability, I did NOT
mean what shows up in perf reports.  I'm talking about whether you can
break at, or single-step through, a function reliably and whether gdb
knows where all the variables are.  In my experience, inlining hurts
both of those things, which is why I'm saying that forcing inlining
even in non-optimized builds is a bad idea.

If we needed this thing to cause inlining even in optimized builds,
there might be a case for it; but that is not what I'm reading in
the gcc manual.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Condition variable live lock
Next
From: Andres Freund
Date:
Subject: Re: Unimpressed with pg_attribute_always_inline