Re: JIT compiling with LLVM v9.0

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: JIT compiling with LLVM v9.0
Date: 2018-02-13 18:50:43
Message-ID: 20180213185043.5mfj4xlsbpxjobz6@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2018-02-13 13:43:40 -0500, Robert Haas wrote:
> On Sun, Feb 11, 2018 at 10:00 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> > I tested several queries in my application that had >30 second compile
> > times against a one second run time,. Not being able to manage when
> > compilation happens is making it difficult to get a sense of llvm
> > performance in the general case.
>
> In theory, the GUCs Andres has added to only compile if the estimated
> total cost is above some threshold is supposed to help with this.

Note that the GUCs as posted are set *way* too low, they're currently
toy thresholds. That's easier for testing, but I guess I should set them
to something better.

It's not unrealistic to expect them to be insufficient however - the
overhead roughly linearly grows with the number of expressions, which
might not reflect the gain equally.

> How did you manage to create an expression that took 30 seconds to
> compile? It doesn't take that long to compile a 5000-line C file.

Any chance a debug build of LLVM was used? The overhead of that are
easily an order of magnitude or more.

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michail Nikolaev 2018-02-13 19:04:26 Re: [WIP PATCH] Index scan offset optimisation using visibility map
Previous Message Robert Haas 2018-02-13 18:43:40 Re: JIT compiling with LLVM v9.0