Hi, On 2018-03-22 10:09:23 +1300, Thomas Munro wrote: > > FWIW, a 32bit chroot, on a 64bit kernel works: > > > > 2018-03-21 20:57:56.576 UTC [3708] DEBUG: successfully loaded LLVM in > > current session > > 2018-03-21 20:57:56.577 UTC [3708] DEBUG: JIT detected CPU "skylake", with > > features > > "+sse2,+cx16,-tbm,-avx512ifma,-avx512dq,-fma4,+prfchw,+bmi2,+xsavec,+fsgsbase,+popcnt,+aes,-pcommit,+xsaves,-avx512er,-clwb,-avx512f,-pku,+smap,+mmx,-xop,+rdseed,+hle,-sse4a,-avx512bw,+clflushopt,+xsave,-avx512vl,+invpcid,-avx512cd,+avx,+rtm,+fma,+bmi,-mwaitx,+rdrnd,+sse4.1,+sse4.2,+avx2,+sse,+lzcnt,+pclmul,-prefetchwt1,+f16c,+ssse3,+sgx,+cmov,-avx512vbmi,+movbe,+xsaveopt,-sha,+adx,-avx512pf,+sse3" > > 2018-03-21 20:57:56.579 UTC [3708] DEBUG: time to inline: 0.000s, opt: > > 0.000s, emit: 0.002s > > > > that's debian testing though. > > Hmm. So now I'm doing this:
I've now reproduced this. It actually only fails for *some* queries, a good number works. Investigating. As a random aside, our costing is fairly ridiculous here: ┌──────────────────────────────────────────────────────────────────────────────┐ │ QUERY PLAN │ ├──────────────────────────────────────────────────────────────────────────────┤ │ Sort (cost=1088314.21..1103119.40 rows=5922075 width=34) │ │ Sort Key: booltbl1.f1, booltbl2.f1 │ │ -> Nested Loop (cost=0.00..118524.73 rows=5922075 width=34) │ │ Join Filter: ((booltbl2.f1 = booltbl1.f1) OR booltbl1.f1) │ │ -> Seq Scan on booltbl1 (cost=0.00..38.10 rows=2810 width=1) │ │ -> Materialize (cost=0.00..52.15 rows=2810 width=1) │ │ -> Seq Scan on booltbl2 (cost=0.00..38.10 rows=2810 width=1) │ │ JIT: │ │ Functions: 6 │ │ Inlining: true │ │ Optimization: true │ └──────────────────────────────────────────────────────────────────────────────┘ > I wonder what I'm doing wrong... what you're doing is very similar, > right? It's a 32 bit user land on a 64 bit kernel whereas mine is a > 32 bit user land on a 32 bit kernel (on a 64 bit CPU). I think it's I that did something wrong not you. And the architecture thing is a non-issue, because we're taking the target triple from the right place. I think it's a separate issue. Notably the generated code is apparently corrupt, when reading in the generated bitcode: $ opt-6.0 -O3 -S < /tmp/data/6814.1.bc|less opt-6.0: <stdin>: error: Invalid record (Producer: 'LLVM6.0.0' Reader: 'LLVM 6.0.0') I suspect there's a 32bit vs 64bit confusion in the expression code somewhere, might've accidentally used a 64bit type for Datum somewhere or such. Will compile an LLVM with assertions enabled, to figure this out (which verifies this kinda thing). Greetings, Andres Freund
