Horton

Re: JIT compiling with LLVM v12

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-09-05T18:35:52Z
Lists: pgsql-hackers 
Hi,

On 2018-08-25 21:34:22 -0400, Robert Haas wrote:
> On Wed, Aug 22, 2018 at 6:43 PM, Andres Freund <andres@anarazel.de> wrote:
> > Now you can say that'd be solved by bumping the cost up, sure. But
> > obviously the row / cost model is pretty much out of whack here, I don't
> > see how we can make reasonable decisions in a trivial query that has a
> > misestimation by five orders of magnitude.
> 
> Before JIT, it didn't matter whether the costing was wrong, provided
> that the path with the lowest cost was the cheapest path (or at least
> close enough to the cheapest path not to bother anyone).

I don't thinkt that's really true. Due to the cost fuzzing absurdly high
cost very commonly lead to the actually different planning choices to
not have a large enough influence to matter.


> I'd guess that, as you read this, you're thinking, well, but if I'd
> added JIT and non-JIT paths for every option, it would have doubled
> the number of paths, and that would have slowed the planner down way
> too much.  That's certainly true, but my point is just that the
> problem is probably not as simple as "the defaults are too low".  I
> think the problem is more fundamentally that the model you've chosen
> is kinda broken.

Right. And that's why I repeatedly brought up this part in
discussions...  I still think it's a reasonable compromise, but it
certainly has costs.

I'm also doubtful that just adding a separate path for JIT (with a
significantly smaller cpu_*_cost or such) would really have helped in
the cases with borked estimations - we'd *still* end up choosing JITing
if the loop count is absurd, just because the cost is high.

There *are* cases where it helps - if all the cost is incurred, say, due
to random page fetches, then JITing isn't going to help that much.


> I'm not saying I know how you could have done any better, but I do
> think we're going to have to try to figure out something to do about
> it, because saying, "check-pg_upgrade is 4x slower, but that's just
> because of all those bad estimates" is not going to fly.

That I'm unconvinced by however. This was on some quite slow machine
and/or with LLVM assertions enabled - the performance difference on a
normal machine is smaller:

$ PGOPTIONS='-cjit=0' time make -s check
...
5.21user 2.11system 0:24.95elapsed 29%CPU (0avgtext+0avgdata 54212maxresident)k
20976inputs+340848outputs (14major+342228minor)pagefaults 0swaps

$ PGOPTIONS='-cjit=1' time make -s check
...
5.33user 2.01system 0:30.49elapsed 24%CPU (0avgtext+0avgdata 54236maxresident)k
0inputs+340856outputs (0major+342616minor)pagefaults 0swaps


But also importantly, I think there's actual advantages in triggering
JIT in some places in the regression tests. There's buildfarm animals
exercising the path that everything is JITed, but that's not really
helpful during development.


> Those bad estimates were harmlessly bad before,

I think that's not true.


Greetings,

Andres Freund

Commits

  1. Improve JIT docs.

  2. Add documentation for the JIT feature.

  3. Add EXPLAIN support for JIT.

  4. Add inlining support to LLVM JIT provider.

  5. JIT tuple deforming in LLVM JIT provider.

  6. Add FIELDNO_* macro designating offset into structs required for JIT.

  7. Add expression compilation support to LLVM JIT provider.

  8. Expand list of synchronized types and functions in LLVM JIT provider.

  9. Add helpers for emitting LLVM IR.

  10. Basic planner and executor integration for JIT.

  11. Debugging and profiling support for LLVM JIT provider.

  12. Support for optimizing and emitting code in LLVM JIT provider.

  13. Add file containing extensions of the LLVM C API.

  14. Basic JIT provider and error handling infrastructure.

  15. Add configure infrastructure (--with-llvm) to enable LLVM support.

  16. Add C++ support to configure.

  17. Add PGAC_PROG_VARCC_VARFLAGS_OPT autoconf macro.

  18. Fix VM buffer pin management in heap_lock_updated_tuple_rec().

  19. Allow tupleslots to have a fixed tupledesc, use in executor nodes.

  20. Expression evaluation based aggregate transition invocation.

  21. Perform slot validity checks in a separate pass over expression.

  22. Rely on executor utils to build targetlist for DML RETURNING.

  23. Refer to OS X as "macOS", except for the port name which is still "darwin".