Re: [HACKERS] Time to drop old-style (V0) functions?
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] Time to drop old-style (V0) functions? |
Дата | |
Msg-id | 20161220095853.mt2bk3r66q5ceafn@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Time to drop old-style (V0) functions? (Pavel Stehule <pavel.stehule@gmail.com>) |
Список | pgsql-hackers |
On 2016-12-20 10:44:35 +0100, Pavel Stehule wrote: > 2016-12-20 10:28 GMT+01:00 Andres Freund <andres@anarazel.de>: > > > On 2016-12-20 01:14:10 -0800, Andres Freund wrote: > > > On 2016-12-20 09:59:43 +0100, Pavel Stehule wrote: > > > > In this case some benchmark can be very important (and interesting). I > > am > > > > not sure if faster function execution has significant benefit on > > Vulcano > > > > like executor. > > > > > > It's fairly to see function calls as significant overhead. In fact, I > > > moved things *away* from a pure Vulcano style executor, and the benefits > > > weren't huge, primarily due to expression evaluation overhead (of which > > > function call overhead is one part). After JITing of expressions, it > > > becomes even more noticeable, because the overhead of the expression > > > evaluation is reduced. > > > > For me a Vulcano style is row by row processing. Using JIT or not using has > not significant impact. > > Interesting change can be block level processing. I don't think that's true. The largest bottlenecks atm have relatively little to do with block level processing. I know, because I went there. We have so many other bottlenecks that row-by-row processing vanishes behind them. Without changing the tuple flow, the performance with either applied or posted patches for TPCH-Q1 already went up by more than a factor of 2.5. Anyway, this seems like a side-track discussion, better done in another thread. Andres
В списке pgsql-hackers по дате отправления: