Re: WIP: Faster Expression Processing and Tuple Deforming (including JIT)
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, Heikki Linnakangas <hlinnaka@iki.fi>, Doug Doole <ddoole@salesforce.com>
Date: 2016-12-06T19:10:59Z
Lists: pgsql-hackers
Hi, On 2016-12-06 13:56:28 -0500, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > I'm posting a quite massive series of WIP patches here, to get some > > feedback. > > I guess the $64 question that has to be addressed here is whether we're > prepared to accept LLVM as a run-time dependency. There are some reasons > why we might not be: Indeed. It'd only be a soft dependency obviously. > * The sheer mass of the dependency. What's the installed footprint of > LLVM, versus a Postgres server? How hard is it to install from source? Worked for me first try, but I'm perhaps not the best person to judge. It does take a while to compile though (~20min on my laptop). > * How will we answer people who say they can't accept having a compiler > installed on their production boxes for security reasons? I think they'll just not enable --with-llvm in that case, and get inferior performance. Note that installing llvm does not imply installing a full blown C compiler (although I think that's largely moot, you can get pretty much the same things done with just compiling LLVM IR). > * Are there any currently-interesting platforms that LLVM doesn't work > for? (I'm worried about RISC-V as much as legacy systems.) LLVM itself I don't think is a problem, it seems to target a wide range of platforms. The platforms that don't support JIT compiling might be a bit larger, since that involves more than just generating code. > I concur with your feeling that hand-rolled JIT is right out. But > I'm not sure that whatever performance gain we might get in this > direction is worth the costs. Well, I'm not impartial, but I don't think we do our users a service by leaving significant speedups untackled, and after spending a *LOT* of time on this, I don't see much other choice than JITing. Note that nearly everything performance sensitive is moving towards doing JITing in some form or another. Greetings, Andres Freund
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