Re: JIT compiling with LLVM v9.0

On Thu, Jan 25, 2018 at 9:40 AM, Konstantin Knizhnik wrote: > As far as I understand generation of native code is now always done for all > supported expressions and individually by each backend. > I wonder it will be useful to do more efforts to understand when

Re: JIT compiling with LLVM v9.0

On Wed, Jan 31, 2018 at 8:53 AM, Robert Haas wrote: > As far as the second one, looking back at what happened with parallel > query, I found (on a quick read) 13 back-patched commits in > REL9_6_STABLE prior to the release of 10.0, 3 of which I would qualify > as

Re: JIT compiling with LLVM v9.0

On 2018-02-09 09:10:25 -0600, Merlin Moncure wrote: > Question: when watching the compilation log, I see quite a few files > being compiled with both O2 and O1, for example: > > clang -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Wendif-labels >

Re: JIT compiling with LLVM v9.0

On Thu, Feb 1, 2018 at 8:16 PM, Thomas Munro wrote: > On Fri, Feb 2, 2018 at 2:05 PM, Andres Freund wrote: >> On 2018-02-01 09:32:17 -0800, Jeff Davis wrote: >>> On Wed, Jan 31, 2018 at 12:03 AM, Konstantin Knizhnik >>>

Re: JIT compiling with LLVM v9.0

Hi, On 2018-02-02 18:22:34 +1300, Thomas Munro wrote: > The clang that was used for bitcode was the system /usr/bin/clang, > version 4.0. Is it a problem that I used that for compiling the > bitcode, but LLVM5 for JIT? I actually tried > CLANG=/usr/local/llvm50/bin/clang but ran into weird

Re: JIT compiling with LLVM v9.0

On 2018-02-01 22:20:01 -0800, Jeff Davis wrote: > Thanks! That worked, but I had to remove the "-stdlib=libc++" also, > which was causing me problems. That'll be gone as soon as I finish the shlib thing. Will hope to have something over the weekend. Right now I'm at FOSDEM and need to prepare a

Re: JIT compiling with LLVM v9.0

Hi, On 2018-02-02 18:22:34 +1300, Thomas Munro wrote: > Is there something broken about my installation? I see simple > arithmetic expressions apparently compiling and working but I can > easily find stuff that breaks... so far I think it's anything > involving string literals: That definitely

Re: JIT compiling with LLVM v9.0

On Thu, Feb 1, 2018 at 10:09 PM, Thomas Munro wrote: > On Fri, Feb 2, 2018 at 7:06 PM, Jeff Davis wrote: >> /usr/include/c++/5/cmath:505:22: error: conflicting declaration of C >> function ‘long double >> ... >> /usr/include/c++/5/cmath:926:3:

Re: JIT compiling with LLVM v9.0

On Fri, Feb 2, 2018 at 7:06 PM, Jeff Davis wrote: > /usr/include/c++/5/cmath:505:22: error: conflicting declaration of C > function ‘long double > ... > /usr/include/c++/5/cmath:926:3: error: template with C linkage I suspect you can fix these with this change: +#ifdef

Re: JIT compiling with LLVM v9.0

On Thu, Feb 1, 2018 at 5:05 PM, Andres Freund wrote: > Just to understand: You're running in the issue with the header being > included from within the extern "C" {}? Hm, I've pushed a quick fix for > that. > > Other than that, you can compile with both gcc or clang, but

Re: JIT compiling with LLVM v9.0

On Fri, Feb 2, 2018 at 5:11 PM, Thomas Munro wrote: > Another small thing which might be environmental... llvmjit_types.bc > is getting installed into ${prefix}/lib here, but you're looking for > it in ${prefix}/lib/postgresql: Is there something broken about my

Re: JIT compiling with LLVM v9.0

Another small thing which might be environmental... llvmjit_types.bc is getting installed into ${prefix}/lib here, but you're looking for it in ${prefix}/lib/postgresql: gmake[3]: Entering directory '/usr/home/munro/projects/postgres/src/backend/lib' /usr/bin/install -c -m 644 llvmjit_types.bc

Re: JIT compiling with LLVM v9.0

On Fri, Feb 2, 2018 at 2:05 PM, Andres Freund wrote: > On 2018-02-01 09:32:17 -0800, Jeff Davis wrote: >> On Wed, Jan 31, 2018 at 12:03 AM, Konstantin Knizhnik >> wrote: >> > The same problem takes place with old versions of GCC: I have to upgrade

Re: JIT compiling with LLVM v9.0

On 2018-02-01 09:32:17 -0800, Jeff Davis wrote: > On Wed, Jan 31, 2018 at 12:03 AM, Konstantin Knizhnik > wrote: > > The same problem takes place with old versions of GCC: I have to upgrade GCC > > to 7.2 to make it possible to compile this code. > > The problem in not

Re: JIT compiling with LLVM v9.0

On Wed, Jan 31, 2018 at 12:03 AM, Konstantin Knizhnik wrote: > The same problem takes place with old versions of GCC: I have to upgrade GCC > to 7.2 to make it possible to compile this code. > The problem in not in compiler itself, but in libc++ headers. How can I get

Re: JIT compiling with LLVM v9.0

On Wed, Jan 31, 2018 at 1:45 PM, Robert Haas wrote: > On Wed, Jan 31, 2018 at 1:34 PM, Andres Freund wrote: >>> The first one is a problem that's not going to go away. If the >>> problem of JIT being enabled "magically" is something we're concerned >>>

Re: JIT compiling with LLVM v9.0

On 2018-02-01 08:46:08 -0500, Peter Eisentraut wrote: > On 1/31/18 14:45, Robert Haas wrote: > > We could do that, but I'd be more inclined just to let JIT be > > magically enabled. In general, if a user could do 'yum install ip4r' > > (for example) and have that Just Work without any further

Re: JIT compiling with LLVM v9.0

On 1/31/18 14:45, Robert Haas wrote: > We could do that, but I'd be more inclined just to let JIT be > magically enabled. In general, if a user could do 'yum install ip4r' > (for example) and have that Just Work without any further database > configuration, One way to do that would be to have a

Re: JIT compiling with LLVM v9.0

On 1/31/18 13:34, Andres Freund wrote: > That's a fair argument, and I don't really have a good answer to it. We > could have a jit = off/try/on, and use that to signal things? I.e. it > can be set to try (possibly default in version + 1), and things will > work if it's not installed, but if set

Re: JIT compiling with LLVM v9.0

On Wed, Jan 31, 2018 at 2:49 PM, Andres Freund wrote: >> We could do that, but I'd be more inclined just to let JIT be >> magically enabled. In general, if a user could do 'yum install ip4r' >> (for example) and have that Just Work without any further database >>

Re: JIT compiling with LLVM v9.0

On 2018-01-31 14:45:46 -0500, Robert Haas wrote: > On Wed, Jan 31, 2018 at 1:34 PM, Andres Freund wrote: > >> The first one is a problem that's not going to go away. If the > >> problem of JIT being enabled "magically" is something we're concerned > >> about, we need to

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-31 11:56:59 -0500, Robert Haas wrote: > On Tue, Jan 30, 2018 at 5:57 PM, Andres Freund wrote: > > Given that we need a shared library it'll be best buildsystem wise if > > all of this is in a directory, and there's a separate file containing > > the stubs that

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-31 11:53:25 -0500, Robert Haas wrote: > On Wed, Jan 31, 2018 at 10:22 AM, Peter Eisentraut > wrote: > > On 1/30/18 21:55, Andres Freund wrote: > >> I'm open to changing my mind on it, but it seems a bit weird that a > >> feature that relies on a

Re: JIT compiling with LLVM v9.0

On Tue, Jan 30, 2018 at 5:57 PM, Andres Freund wrote: > Given that we need a shared library it'll be best buildsystem wise if > all of this is in a directory, and there's a separate file containing > the stubs that call into it. > > I'm not quite sure where to put the code.

Re: JIT compiling with LLVM v9.0

On Wed, Jan 31, 2018 at 10:22 AM, Peter Eisentraut wrote: > On 1/30/18 21:55, Andres Freund wrote: >> I'm open to changing my mind on it, but it seems a bit weird that a >> feature that relies on a shlib being installed magically turns itself on >> if avaible.

Re: JIT compiling with LLVM v9.0

On 1/30/18 21:55, Andres Freund wrote: > I'm open to changing my mind on it, but it seems a bit weird that a > feature that relies on a shlib being installed magically turns itself on > if avaible. And leaving that angle aside, ISTM, that it's a complex > enough feature that it should be opt-in

Re: JIT compiling with LLVM v9.0

On 31.01.2018 05:48, Thomas Munro wrote: This seems to be a valid complaint. I don't think you should be (indirectly) wrapping Types.h in extern "C". At a guess, your llvmjit.h should be doing its own #ifdef __cplusplus'd linkage specifiers, so you can use it from C or C++, but making sure

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-31 15:48:09 +1300, Thomas Munro wrote: > On Wed, Jan 31, 2018 at 3:05 PM, Andres Freund wrote: > > I'm not quite sure I understand. You mean have it display whether > > available? I think my plan is to "just" set jit_expressions=on (or > > whatever we're going

Re: JIT compiling with LLVM v9.0

On Wed, Jan 31, 2018 at 3:05 PM, Andres Freund wrote: > On 2018-01-31 14:42:26 +1300, Thomas Munro wrote: >> I'm just starting to look at this (amazing) work, and I don't have a >> strong opinion yet. But certainly, making it easy for packagers to >> put the -jit stuff into a

Re: JIT compiling with LLVM v9.0

On 2018-01-31 14:42:26 +1300, Thomas Munro wrote: > I'm just starting to look at this (amazing) work, and I don't have a > strong opinion yet. But certainly, making it easy for packagers to > put the -jit stuff into a separate package for the reasons already > given sounds sensible to me. Some

Re: JIT compiling with LLVM v9.0

On Wed, Jan 31, 2018 at 11:57 AM, Andres Freund wrote: > On 2018-01-30 13:46:37 -0500, Robert Haas wrote: >> On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote: >> > It's an optional dependency, and it doesn't increase build time that >> > much... If we

Re: JIT compiling with LLVM v9.0

> On Jan 30, 2018, at 2:08 PM, Andres Freund wrote: > > With things like apt recommends and such I don't think this is a huge problem. I don’t believe there is a similar widely-supported dependency type in yum/rpm, though. rpm 4.12 adds support for Weak Dependencies, which

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-30 13:46:37 -0500, Robert Haas wrote: > On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote: > > It's an optional dependency, and it doesn't increase build time that > > much... If we were to move the llvm interfacing code to a .so, there'd > > not even be a

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-30 22:57:06 +0100, David Fetter wrote: > On Tue, Jan 30, 2018 at 01:46:37PM -0500, Robert Haas wrote: > > On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote: > > > It's an optional dependency, and it doesn't increase build time > > > that much... If we were

Re: JIT compiling with LLVM v9.0

On Tue, Jan 30, 2018 at 01:46:37PM -0500, Robert Haas wrote: > On Mon, Jan 29, 2018 at 1:40 PM, Andres Freund wrote: > > It's an optional dependency, and it doesn't increase build time > > that much... If we were to move the llvm interfacing code to a > > .so, there'd not even

Re: JIT compiling with LLVM v9.0

On 01/30/2018 12:24 AM, Andres Freund wrote: > Hi, > > On 2018-01-30 00:16:46 +0100, Tomas Vondra wrote: >> FWIW I've installed llvm 5.0.1 from distribution package, and now >> everything builds fine (I don't even need the configure tweak). >> >> I think I had to build the other binaries

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-30 15:06:02 -0500, Robert Haas wrote: > On Tue, Jan 30, 2018 at 2:08 PM, Andres Freund wrote: > >> That bites, although it's probably tolerable if we expect such errors > >> only in exceptional situations such as a needed shared library failing > >> to load or

Re: JIT compiling with LLVM v9.0

Robert Haas writes: > Unfortunately, that has the pretty significant downside that a lot of > people who actually want the postgresql-server-jit package will not > realize that they need to install it, which sucks. But I think it > might still be the better way to go.

Re: JIT compiling with LLVM v9.0

On Tue, Jan 30, 2018 at 2:08 PM, Andres Freund wrote: >> That bites, although it's probably tolerable if we expect such errors >> only in exceptional situations such as a needed shared library failing >> to load or something. Killing the session when we run out of memory >>

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-30 13:57:50 -0500, Robert Haas wrote: > > When a libstdc++ new or LLVM error occurs, the handlers set up by the > > above functions trigger a FATAL error. We have to use FATAL rather than > > ERROR, as we *cannot* reliably throw ERROR inside a foreign library > > without risking

Re: JIT compiling with LLVM v9.0

On Wed, Jan 24, 2018 at 2:20 AM, Andres Freund wrote: > == Error handling == > > There's two aspects to error handling. > > Firstly, generated (LLVM IR) and emitted functions (mmap()ed segments) > need to be cleaned up both after a successful query execution and after > an

Re: JIT compiling with LLVM v9.0

Hi, On Mon, Jan 29, 2018 at 10:40 AM, Andres Freund wrote: > Hi, > > On 2018-01-29 10:28:18 -0800, Jeff Davis wrote: >> OK. How about this: are you open to changes that move us in the >> direction of extensibility later? (By this I do *not* mean imposing a >> bunch of

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-30 00:16:46 +0100, Tomas Vondra wrote: > FWIW I've installed llvm 5.0.1 from distribution package, and now > everything builds fine (I don't even need the configure tweak). > > I think I had to build the other binaries because there was no 5.x llvm > back then, but it's too far

Re: JIT compiling with LLVM v9.0

On 01/29/2018 11:49 PM, Tomas Vondra wrote: > > ... > > and that indeed changes the failure to this: > > Writing postgres.bki > Writing schemapg.h > Writing postgres.description > Writing postgres.shdescription > llvmjit_error.cpp: In function ‘void llvm_enter_fatal_on_oom()’: >

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-29 23:49:14 +0100, Tomas Vondra wrote: > On 01/29/2018 11:17 PM, Andres Freund wrote: > > On 2018-01-29 23:01:14 +0100, Tomas Vondra wrote: > >> $ llvm-config --version > >> 5.0.0svn > > > > Is thta llvm-config the one in /usr/local/include/ referenced by the > > error message

Re: JIT compiling with LLVM v9.0

On 01/29/2018 11:17 PM, Andres Freund wrote: > On 2018-01-29 23:01:14 +0100, Tomas Vondra wrote: >> On 01/29/2018 10:57 PM, Andres Freund wrote: >>> Hi, >>> >>> On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote: Hi, I wanted to look at this, but my attempts to build the jit branch fail

Re: JIT compiling with LLVM v9.0

On 2018-01-29 23:01:14 +0100, Tomas Vondra wrote: > On 01/29/2018 10:57 PM, Andres Freund wrote: > > Hi, > > > > On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote: > >> Hi, I wanted to look at this, but my attempts to build the jit branch > >> fail with some compile-time warnings (uninitialized

Re: JIT compiling with LLVM v9.0

On 01/29/2018 10:57 PM, Andres Freund wrote: > Hi, > > On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote: >> Hi, I wanted to look at this, but my attempts to build the jit branch >> fail with some compile-time warnings (uninitialized variables) and >> errors (unknown types, incorrect number of

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-29 22:51:38 +0100, Tomas Vondra wrote: > Hi, I wanted to look at this, but my attempts to build the jit branch > fail with some compile-time warnings (uninitialized variables) and > errors (unknown types, incorrect number of arguments). See the file > attached. Which git hash are

Re: JIT compiling with LLVM v9.0

On 01/24/2018 08:20 AM, Andres Freund wrote: > Hi, > > I've spent the last weeks working on my LLVM compilation patchset. In > the course of that I *heavily* revised it. While still a good bit away > from committable, it's IMO definitely not a prototype anymore. > > There's too many small

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-29 10:28:18 -0800, Jeff Davis wrote: > OK. How about this: are you open to changes that move us in the > direction of extensibility later? (By this I do *not* mean imposing a > bunch of requirements on you... either small changes to your patches > or something part of another

Re: JIT compiling with LLVM v9.0

On Mon, Jan 29, 2018 at 1:36 AM, Andres Freund wrote: > There's already a *lot* of integration points in the patchseries. Error > handling needs to happen in parts of code we do not want to make > extensible, the defintion of expression steps has to exactly match, the > core

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-29 15:45:56 +0300, Konstantin Knizhnik wrote: > On 26.01.2018 22:38, Andres Freund wrote: > > And without it perf is not able to unwind stack trace for generated > > > code. > > You can work around that by using --call-graph lbr with a sufficiently > > new perf. That'll not know

Re: JIT compiling with LLVM v9.0

On 26.01.2018 22:38, Andres Freund wrote: And without it perf is not able to unwind stack trace for generated code. You can work around that by using --call-graph lbr with a sufficiently new perf. That'll not know function names et al, but at least the parent will be associated correctly.

Re: JIT compiling with LLVM v9.0

On Monday, January 29, 2018 10:46:13 AM CET Andres Freund wrote: > Hi, > > On 2018-01-28 23:02:56 +0100, Pierre Ducroquet wrote: > > I have fixed the build issues with LLVM 3.9 and 4.0. The LLVM > > documentation is really lacking when it comes to porting from version x > > to x+1. > > The only

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-28 23:02:56 +0100, Pierre Ducroquet wrote: > I have fixed the build issues with LLVM 3.9 and 4.0. The LLVM documentation > is > really lacking when it comes to porting from version x to x+1. > The only really missing part I found is that in 3.9, GlobalValueSummary has > no >

Re: JIT compiling with LLVM v9.0

On Thursday, January 25, 2018 8:02:54 AM CET Andres Freund wrote: > Hi! > > On 2018-01-24 22:51:36 -0800, Jeff Davis wrote: > > Can we store the bitcode in pg_proc, simplifying deployment and > > allowing extensions to travel over replication? > > Yes, we could. You'd need to be a bit careful

Re: JIT compiling with LLVM v9.0

On Thursday, January 25, 2018 8:12:42 PM CET Andres Freund wrote: > Hi, > > On 2018-01-25 10:00:14 +0100, Pierre Ducroquet wrote: > > I don't know when this would be released, > > August-October range. > > > but the minimal supported LLVM > > version will have a strong influence on the

Re: JIT compiling with LLVM v9.0

On Sat, Jan 27, 2018 at 5:15 PM, Andres Freund wrote: >> Also, I'm sure you considered this, but I'd like to ask if we can try >> harder make the JIT itself happen in an extension. It has some pretty >> huge benefits: > > I'm very strongly against this. To the point that I'll

Re: JIT compiling with LLVM v9.0

On Sat, Jan 27, 2018 at 1:20 PM, Andres Freund wrote: > b) The optimizations to take advantage of the constants and make the >code faster with the constant tupledesc is fairly slow (you pretty >much need at least an -O2 equivalent), whereas the handrolled tuple >

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-26 22:52:35 -0800, Jeff Davis wrote: > The version of LLVM that I tried this against had a linker option > called "InternalizeLinkedSymbols" that would prevent the visibility > problem you mention (assuming I understand you correctly). I don't think they're fully solvable - you

Re: JIT compiling with LLVM v9.0

Hi, On Fri, Jan 26, 2018 at 6:40 PM, Andres Freund wrote: >> I would like to see if we can get a combination of JIT and LTO to work >> together to specialize generic code at runtime. > > Well, LTO can't quite work. It relies on being able to mark code in > modules linked

Re: JIT compiling with LLVM v9.0

On Wed, Jan 24, 2018 at 11:02 PM, Andres Freund wrote: > Not entirely sure what you mean. You mean why I don't inline > slot_getsomeattrs() etc and instead generate code manually? The reason > is that the generated code is a *lot* smarter due to knowing the > specific

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-26 13:06:27 +0300, Konstantin Knizhnik wrote: > One more question: do you have any idea how to profile JITed code? Yes ;). It depends a bit on what exactly you want to do. Is it sufficient to get time associated with the parent caller, or do you need instruction-level access. >

Re: JIT compiling with LLVM v9.0

On Thu, Jan 25, 2018 at 11:20:28AM -0800, Andres Freund wrote: > On 2018-01-25 18:40:53 +0300, Konstantin Knizhnik wrote: > > Another question is whether it is sensible to redundantly do > > expensive work (llvm compilation) in all backends. > > Right now we kinda have to, but I really want to

Re: JIT compiling with LLVM v9.0

On 26.01.2018 11:23, Andres Freund wrote: Hi, Thanks for testing things out! Thank you for this work. One more question: do you have any idea how to profile JITed code? There is no LLVMOrcRegisterPerf in LLVM 5, so jit_profiling_support option does nothing. And without it perf is not able

Re: JIT compiling with LLVM v9.0

Hi, Thanks for testing things out! On 2018-01-26 10:44:24 +0300, Konstantin Knizhnik wrote: > Also I noticed that parallel execution didsables JIT. Oh, oops, I broke that recently by moving where the decisition about whether to jit or not is. There actually is JITing, but only in the leader.

Re: JIT compiling with LLVM v9.0

Hi, I've spent the last weeks working on my LLVM compilation patchset. In the course of that I *heavily* revised it. While still a good bit away from committable, it's IMO definitely not a prototype anymore. Below are results on my system for Q1 TPC-H scale 10 (~13Gb database) Options

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-25 10:00:14 +0100, Pierre Ducroquet wrote: > I don't know when this would be released, August-October range. > but the minimal supported LLVM > version will have a strong influence on the availability of that feature. If > today this JIT compiling was released with only LLVM

Re: JIT compiling with LLVM v9.0

On 24.01.2018 10:20, Andres Freund wrote: Hi, I've spent the last weeks working on my LLVM compilation patchset. In the course of that I *heavily* revised it. While still a good bit away from committable, it's IMO definitely not a prototype anymore. There's too many small changes, so I'm

Re: JIT compiling with LLVM v9.0

On Thursday, January 25, 2018 7:38:16 AM CET Andres Freund wrote: > Hi, > > On 2018-01-24 22:33:30 -0800, Jeff Davis wrote: > > On Wed, Jan 24, 2018 at 1:35 PM, Pierre Ducroquet wrote: > > > In LLVM 5.0, it looks like DebugInfo.h is not available in llvm-c, only > > > as a

Re: JIT compiling with LLVM v9.0

On Tue, Jan 23, 2018 at 11:20 PM, Andres Freund wrote: > Hi, > > I've spent the last weeks working on my LLVM compilation patchset. In > the course of that I *heavily* revised it. While still a good bit away > from committable, it's IMO definitely not a prototype anymore.

Re: JIT compiling with LLVM v9.0

On Wed, Jan 24, 2018 at 1:35 PM, Pierre Ducroquet wrote: > In LLVM 5.0, it looks like DebugInfo.h is not available in llvm-c, only as a C > ++ API in llvm/IR/DebugInfo.h. The LLVM APIs don't seem to be very stable; won't there just be a continuous stream of similar issues?

Re: JIT compiling with LLVM v9.0

Hi, On 2018-01-24 14:06:30 -0800, Andres Freund wrote: > > In LLVM 5.0, it looks like DebugInfo.h is not available in llvm-c, only as > > a C > > ++ API in llvm/IR/DebugInfo.h. > > Hm, I compiled against 5.0 quite recently, but added the stripping of > debuginfo lateron. I'll add a fallback

Re: JIT compiling with LLVM v9.0

On Wednesday, January 24, 2018 8:20:38 AM CET Andres Freund wrote: > As the patchset is large (500kb) and I'm still quickly evolving it, I do > not yet want to attach it. The git tree is at > https://git.postgresql.org/git/users/andresfreund/postgres.git > in the jit branch > >