Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

Hi, On 2017-02-10 18:18:13 +0100, Markus Nullmeier wrote: > Well, if this thread of thought about hand-crafted JIT should be taken > up again by someone at some point in time, I guess it could be possible > to reuse tools that are already out there, such as "DynASM" > (

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

On 12/06/16 21:40, Andres Freund wrote: > On 2016-12-06 14:35:43 -0600, Nico Williams wrote: >> On Tue, Dec 06, 2016 at 12:27:51PM -0800, Andres Freund wrote: >>> On 2016-12-06 14:19:21 -0600, Nico Williams wrote: > I concur with your feeling that hand-rolled JIT is right out. But

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

On Tue, Dec 6, 2016 at 11:10:59AM -0800, Andres Freund wrote: > > 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

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

On Mon, Dec 12, 2016 at 6:14 PM, Andres Freund wrote: > > > For Q1 I think the bigger win is JITing the transition function > invocation in advance_aggregates/transition_function - that's IIRC where > the biggest bottleneck lies. > Yeah, we bundle the agg core into our expr

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

Hi, On 2016-12-12 18:11:13 -0800, CK Tan wrote: > Andres, > > dev (no jiting): > > Time: 30343.532 ms > > > dev (jiting): > > SET jit_tuple_deforming = on; > > SET jit_expressions = true; > > > > Time: 24439.803 ms > > FYI, ~20% improvement for TPCH Q1 is consistent with what we find when we >

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

Andres, > dev (no jiting): > Time: 30343.532 ms > dev (jiting): > SET jit_tuple_deforming = on; > SET jit_expressions = true; > > Time: 24439.803 ms FYI, ~20% improvement for TPCH Q1 is consistent with what we find when we only jit expression. Cheers, -cktan

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

On Tue, Dec 6, 2016 at 9:19 AM, Andres Freund wrote: > 0009 WIP: Add minimal keytest implementation. > > More or less experimental patch that tries to implement simple > expression of the OpExpr(ScalarVar, Const) into a single expression > evaluation step. The benefits

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

On 7 December 2016 at 14:39, Craig Ringer wrote: > On 7 December 2016 at 04:13, Robert Haas wrote: > >> I wonder how feasible it would be to make this a run-time dependency >> rather than a compile option. > > Or something that's compiled with the

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

On 7 December 2016 at 04:13, Robert Haas wrote: > I wonder how feasible it would be to make this a run-time dependency > rather than a compile option. Or something that's compiled with the server, but produces a separate .so that's the only thing that links to LLVM. So

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

On 2016-12-06 13:27:14 -0800, Peter Geoghegan wrote: > On Mon, Dec 5, 2016 at 7:49 PM, Andres Freund wrote: > > I tried to address 2) by changing the C implementation. That brings some > > measurable speedups, but it's not huge. A bigger speedup is making > > slot_getattr,

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

On Mon, Dec 5, 2016 at 7:49 PM, Andres Freund wrote: > I tried to address 2) by changing the C implementation. That brings some > measurable speedups, but it's not huge. A bigger speedup is making > slot_getattr, slot_getsomeattrs, slot_getallattrs very trivial wrappers; > but

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

On Tue, Dec 06, 2016 at 12:36:41PM -0800, Andres Freund wrote: > On 2016-12-06 15:25:44 -0500, Tom Lane wrote: > > I'm not entirely thrilled with the idea of this being a configure-time > > decision, because that forces packagers to decide for their entire > > audience whether it's okay to depend

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

On 2016-12-06 14:35:43 -0600, Nico Williams wrote: > On Tue, Dec 06, 2016 at 12:27:51PM -0800, Andres Freund wrote: > > On 2016-12-06 14:19:21 -0600, Nico Williams wrote: > > > > I concur with your feeling that hand-rolled JIT is right out. But > > > > > > Yeah, that way lies maintenance

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

On 2016-12-06 15:25:44 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2016-12-06 13:56:28 -0500, Tom Lane wrote: > >> 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 >

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

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,

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

Hi, 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

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

Andres Freund writes: > On 2016-12-06 13:56:28 -0500, Tom Lane wrote: >> 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

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

On Tue, Dec 06, 2016 at 01:56:28PM -0500, Tom Lane wrote: > Andres Freund 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

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

On 2016-12-06 15:13:21 -0500, Robert Haas wrote: > Presumably this is going to need to be something that a user can get > via yum install or apt-get install on common systems. Right. apt-get install llvm-dev (or llvm-3.9-dev or such if you want to install a specific version), does the trick

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

On Tue, Dec 6, 2016 at 2:10 PM, Andres Freund wrote: >> * 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.

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

On 2016-12-06 11:10:59 -0800, Andres Freund wrote: > > * 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

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

On 2016-12-06 14:04:09 -0500, Robert Haas wrote: > I've heard at least one and maybe several PGCon presentations about > people JITing tuple deformation and getting big speedups, and I'd like > to finally hear one from somebody who intends to integrate that into > PostgreSQL. I certainly want to.

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

Hi, On 2016-12-06 13:56:28 -0500, Tom Lane wrote: > Andres Freund 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

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

On Tue, Dec 6, 2016 at 1:56 PM, Tom Lane wrote: > Andres Freund 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

Re: [HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

Andres Freund 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: *

[HACKERS] WIP: Faster Expression Processing and Tuple Deforming (including JIT)

Hi Everyone, TL;DR: Making things faster. Architectural evalation. as some of you might be aware I've been working on making execution of larger queries in postgresl faster. While working on "batched execution" I came to the conclusion that, while necessary, isn't currently showing a large