Postgres Pro
Downloads
Home   >   mailing lists

Re: Query JITing with LLVM ORC - Mailing list pgsql-hackers

From João Paulo Labegalini de Carvalho
Subject Re: Query JITing with LLVM ORC
Date
Msg-id CAGjvy29hp2Oe8Suxrbnw6A5=906FhbutOjt1-zY_FHqzP4dSCg@mail.gmail.com
Whole thread Raw
In response to Re: Query JITing with LLVM ORC  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Query JITing with LLVM ORC
Re: Query JITing with LLVM ORC
List pgsql-hackers
Tree view
Hi Thomas,

It JITs expressions but not whole queries.

Thanks for the clarification.
 
Query execution at the
tuple-flow level is still done using a C call stack the same shape as
the query plan, but it *could* be transformed to a different control
flow that could be run more efficiently and perhaps JITed.

I see, so there is room for extending the use of Orc JIT in PGSQL.
 
CCing
Andres who developed all this and had some ideas about that...

Thanks for CCing Andres, it will be great to hear from him.
 
> I would love to know what motivated this feature and for what it is being currently used for,

https://www.postgresql.org/docs/current/jit-reason.html

In that link I found the README under src/backend/jit, which was very helpful. 

> as it is not enabled by default.

It's enabled by default in v12 and higher (if you built with
--with-llvm, as packagers do), but not always used:

https://www.postgresql.org/docs/current/jit-decision.html

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?

Regards,

--
João Paulo L. de Carvalho
Ph.D Computer Science |  IC-UNICAMP | Campinas , SP - Brazil
Postdoctoral Research Fellow | University of Alberta | Edmonton, AB - Canada

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Reducing the WAL overhead of freezing in VACUUM by deduplicating per-tuple freeze plans
Next
From: Andrey Chudnovskiy
Date:
Subject: RE: [EXTERNAL] Re: [PoC] Federated Authn/z with OAUTHBEARER