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
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 |