Re: Query JITing with LLVM ORC

Поиск
Список
Период
Сортировка
От João Paulo Labegalini de Carvalho
Тема Re: Query JITing with LLVM ORC
Дата
Msg-id CAGjvy29hp2Oe8Suxrbnw6A5=906FhbutOjt1-zY_FHqzP4dSCg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Query JITing with LLVM ORC  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: Query JITing with LLVM ORC  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Query JITing with LLVM ORC  (Thomas Munro <thomas.munro@gmail.com>)
Список pgsql-hackers
Дерево обсуждения
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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Reducing the WAL overhead of freezing in VACUUM by deduplicating per-tuple freeze plans
Следующее
От: Andrey Chudnovskiy
Дата:
Сообщение: RE: [EXTERNAL] Re: [PoC] Federated Authn/z with OAUTHBEARER