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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Doug Doole <ddoole(at)salesforce(dot)com>
Subject: Re: WIP: Faster Expression Processing and Tuple Deforming (including JIT)
Date: 2016-12-06 19:10:59
Message-ID: 20161206191059.xnm43zi36p2xkfhg@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2016-12-06 13:56:28 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-12-06 19:12:55 Re: WIP: Faster Expression Processing and Tuple Deforming (including JIT)
Previous Message Joseph Brenner 2016-12-06 19:04:21 Re: Select works only when connected from login postgres