Re: WIP: Faster Expression Processing and Tuple Deforming (including JIT)
Nico Williams <nico@cryptonector.com>
From: Nico Williams <nico@cryptonector.com>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org, Heikki Linnakangas <hlinnaka@iki.fi>, Doug Doole <ddoole@salesforce.com>
Date: 2016-12-06T20:35:43Z
Lists: pgsql-hackers
On Tue, Dec 06, 2016 at 12:27:51PM -0800, Andres Freund wrote: > On 2016-12-06 14:19:21 -0600, Nico Williams wrote: > > A bigger concern might be interface stability. IIRC the LLVM C/C++ > > interfaces are not very stable, but bitcode is. > > The C API is a lot more stable than the C++ bit, that's the primary > reason I ended up using it, despite the C++ docs being better. Ah. > > > I concur with your feeling that hand-rolled JIT is right out. But > > > > Yeah, that way lies maintenance madness. > > I'm not quite that sure about that. I had a lot of fun doing some > hand-rolled x86 JITing. Not that is a ward against me being mad. But > more seriously: Manually doing a JIT gives you a lot faster compilation > times, which makes JIT applicable in a lot more situations. What I meant is that each time there are new ISA extensions, or differences in how relevant/significant different implementations of the same ISA implement certain instructions, and/or every time you want to add a new architecture... someone has to do a lot of very low-level work. > > > I'm not sure that whatever performance gain we might get in this > > > direction is worth the costs. > > > > Byte-/bit-coding query plans then JITting them is very likely to improve > > performance significantly. > > Note that what I'm proposing is a far cry away from that - this converts > two (peformance wise two, size wise one) significant subsystems, but far > from all the executors to be JIT able. I think there's some more low Yes, I know. > hanging fruits (particularly aggregate transition functions), but > converting everything seems to hit the wrong spot in the > benefit/effort/maintainability triangle. Maybe? At least with the infrastructure in place for it someone might try it and see. Nico --
Commits
-
Improve performance of ExecEvalWholeRowVar.
- 2f0903ea1965 10.0 landed
-
Remove unreachable code in expression evaluation.
- ad46a2aa79f9 10.0 landed
-
Faster expression evaluation and targetlist projection.
- b8d7f053c5c2 10.0 landed
-
Avoid syntax error on platforms that have neither LOCALE_T nor ICU.
- 457a44487328 10.0 cited
-
Add configure test to see if the C compiler has gcc-style computed gotos.
- bc18126a6bcb 10.0 landed
-
Improve regression test coverage for TID scanning.
- be6c3d19fd45 10.0 landed
-
Improve expression evaluation test coverage.
- ce38949ba23a 10.0 landed
-
Fix two errors with nested CASE/WHEN constructs.
- f0c7b789ab12 9.6.0 cited