Re: FUNC_MAX_ARGS benchmarks - Mailing list pgsql-hackers

From Tom Lane
Subject Re: FUNC_MAX_ARGS benchmarks
Date
Msg-id 120.1028299187@sss.pgh.pa.us
Whole thread Raw
In response to Re: FUNC_MAX_ARGS benchmarks  (Rod Taylor <rbt@zort.ca>)
Responses Re: FUNC_MAX_ARGS benchmarks  (Andrew Sullivan <andrew@libertyrms.info>)
List pgsql-hackers
Rod Taylor <rbt@zort.ca> writes:
> Perhaps I'm not remembering correctly, but don't SQL functions still
> have an abnormally high cost of execution compared to plpgsql? 

> Want to try the same thing with a plpgsql function?

Actually, plpgsql is pretty expensive too.  The thing to be benchmarking
is applications of plain old built-in-C functions and operators.

Also, there are two components that I'd be worried about: one is the
parser's costs of operator/function lookup, and the other is runtime
overhead.  Runtime overhead is most likely concentrated in the fmgr.c
interface functions, which tend to do MemSets to zero out function
call records.  I had had a todo item to eliminate the memset in favor
of just zeroing what needs to be zeroed, at least in the one- and two-
argument cases which are the most heavily trod code paths.  This will
become significantly more important if FUNC_MAX_ARGS increases.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Why is MySQL more chosen over PostgreSQL?
Next
From: Greg Copeland
Date:
Subject: Re: WAL file location