Re: Unimpressed with pg_attribute_always_inline
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>,
pgsql-hackers@lists.postgresql.org
Date: 2018-01-09T00:12:08Z
Lists: 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
Commits
-
Improve implementation of pg_attribute_always_inline.
- 434e6e148441 11.0 landed
-
Add pg_attribute_always_inline.
- dbb3d6f0102e 11.0 cited