On Tue, Oct 26, 2010 at 12:28 AM, Tom Lane <t...@sss.pgh.pa.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
