On 2016-12-20 10:44:35 +0100, Pavel Stehule wrote: > 2016-12-20 10:28 GMT+01:00 Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
