Re: FUNC_MAX_ARGS benchmarks
От | Tom Lane |
---|---|
Тема | Re: FUNC_MAX_ARGS benchmarks |
Дата | |
Msg-id | 120.1028299187@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: FUNC_MAX_ARGS benchmarks (Rod Taylor <rbt@zort.ca>) |
Ответы |
Re: FUNC_MAX_ARGS benchmarks
|
Список | 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 по дате отправления: