From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | João Paulo Labegalini de Carvalho <jaopaulolc(at)gmail(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: Query JITing with LLVM ORC |
Date: | 2022-09-21 22:35:53 |
Message-ID: | 1297373.1663799753@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
=?UTF-8?Q?Jo=C3=A3o_Paulo_Labegalini_de_Carvalho?= <jaopaulolc(at)gmail(dot)com> writes:
> Good to know. I compiled from the REL_14_5 tag and did a simple experiment
> to contrast building with and w/o passing --with-llvm.
> I ran the TPC-C benchmark with 1 warehouse, 10 terminals, 20min of ramp-up,
> and 120 of measurement time.
> The number of transactions per minute was about the same with & w/o JITing.
> Is this expected? Should I use a different benchmark to observe a
> performance difference?
TPC-C is mostly short queries, so we aren't likely to choose to use JIT
(and if we did, it'd likely be slower). You need a long query that will
execute the same expressions over and over for it to make sense to
compile them. Did you check whether any JIT was happening there?
There are a bunch of issues in this area concerning whether our cost
models are good enough to accurately predict whether JIT is a good
idea. But single-row fetches and updates are basically never going
to use it, nor should they.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2022-09-21 22:36:41 | Re: [PoC] Let libpq reject unexpected authentication requests |
Previous Message | Jacob Champion | 2022-09-21 22:31:29 | Re: [EXTERNAL] Re: [PoC] Federated Authn/z with OAUTHBEARER |