Re: Extensible executor nodes for preparation of SQL/MED

On Tue, Oct 26, 2010 at 12:28 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> But it might be a good change anyway from a performance standpoint,
> in case a call through a function pointer is faster than a big switch.
> Have you tried benchmarking it on common platforms?

I didn't intend performance, but there is small but measurable win
in it if I avoided indirections. We might not always need to copy
a whole vtable into planstate; only ExecProcNode might be enough.
I'll continue the research.

24957.767 ms : master (a big switch)
25059.838 ms : two indirections (planstate->plan->vtable->fn)
24819.298 ms : one indirection (planstate->plan->vtable.fn)
24118.436 ms : direct call (planstate->vtable.fn)

So, major benefits of the change might be performance and code refactoring.
Does anyone have comments about it for the functionality? It might also be
used by SQL/MED and executor hooks, but I have no specific idea yet.

[measuring settings and queries]
=# SHOW shared_buffers;
shared_buffers
----------------
512MB

=# CREATE TABLE tbl AS SELECT i FROM generate_series(1, 10000000) AS t(i);
=# VACUUM ANALYZE tbl;
=# SELECT count(*), pg_size_pretty(pg_relation_size('tbl')) FROM tbl;
=# CREATE FUNCTION test(n integer) RETURNS void LANGUAGE plpgsql AS
$$
DECLARE
i integer;
r bigint;
BEGIN
FOR i IN 1..n LOOP
SELECT count(*) INTO r FROM tbl;
END LOOP;
END;
$$;

=# \timing
=# SELECT test(30);

--
Itagaki Takahiro