Re: [HACKERS] Time to drop old-style (V0) functions?

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.

As an example, here's a JITed TPCH Q1 profile:
+   15.48%  postgres  postgres                          [.] slot_deform_tuple
+    8.42%  postgres  perf-27760.map                    [.] evalexpr90
+    5.98%  postgres  postgres                          [.] float8_accum
+    4.63%  postgres  postgres                          [.] slot_getattr
+    3.69%  postgres  postgres                          [.] bpchareq
+    3.39%  postgres  postgres                          [.] heap_getnext
+    3.22%  postgres  postgres                          [.] float8pl
+    2.86%  postgres  postgres                          [.] TupleHashTableMatch.isra.7
+    2.77%  postgres  postgres                          [.] hashbpchar
+    2.77%  postgres  postgres                          [.] float8mul
+    2.73%  postgres  postgres                          [.] ExecAgg
+    2.40%  postgres  postgres                          [.] hash_any
+    2.34%  postgres  postgres                          [.] MemoryContextReset
+    1.98%  postgres  postgres                          [.] pg_detoast_datum_packed

evalexpr90 is the expression that does the aggregate transition
function. float8_accum, bpchareq, float8pl , float8mul, ...  are all
function calls, and a good percentage of the overhead in evalexpr90 is
pushing arguments onto fcinfo->arg[nulls].

Greetings,

Andres Freund